Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Harsha Kumara]

On Tue, Oct 23, 2018 at 10:07 AM Uvindra Dias Jayasinha 
wrote:

> @Bhathiya Jayasekara 
> yes, this is also an option. In reality though very few customers upload
> lots of additional docs. We could just rename DOC_META_DATA table to DOCS
> and store the docs in that table itself. So at the very minimum we have a
> swagger and ballerina definition per an API stored in the RESOURCES table.
>
Definitely we should have a separate table for docs.

>
> Can we make a call on this soon? Implementation is getting delayed because
> of this.
>
> On Mon, 22 Oct 2018 at 21:08, Bhathiya Jayasekara 
> wrote:
>
>> This looks ok. Btw, I was wondering if it's a good idea to have all files
>> (swaggers, wsdls, docs etc.) in a single table. Won't that make the table
>> grow faster and make querying slower? How about keeping a separate table
>> for this? Then we can have a foreign key as well.
>>
>> Thanks,
>> Bhathiya
>>
>> On Mon, Oct 22, 2018 at 2:57 PM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> +1, CONTENT  is fine
>>>
>>> On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:
>>>
 Hi Uvindra,

 Please find the data types below

 *AM_API_DOC_META_DATA*
 API_ID (This will be a foreign key referred to AM_API table)
 VARCHAR(255)
 RESOURCE_ID VARCHAR(255)
 DOC_CONTENT VARCHAR(1024)

 *AM_API_RESOURCES*
 RESOURCE_NAME VARCHAR(255)

 And I think we can change it DOC_CONTENT to CONTENT .
 WDYT?

 Thanks & Regards,
 Mushthaq

 On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> HI Mushtaq,
>
> Can you provide the data types of the columns so that this is more
> clear? I believe that DOC_CONTENT should be a VARCHAR, in that case better
> to call it something like SHORT_CONTENT, since this communicates that it 
> is
> meant to share relatively short text values such as URL and inline text.
> The name DOC_CONTENT is misleading and might suggest we can store larger
> documents in this column.
>
> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>
>> Hi All,
>>
>> We had an internal discussion and decided to do some modifications in
>> the DB Schema related to API Docs (AM_API_RESOURCES and
>> AM_API_DOC_META_DATA). We will be removing the foreign key constraint 
>> added
>> to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
>> the primary key of AM_API_RESOURCES which is not a good practice.
>>
>> And the following columns will be added to the respective tables.
>>
>> *AM_API_DOC_META_DATA*
>> API_ID (This will be a foreign key referred to AM_API table)
>> RESOURCE_ID
>> DOC_CONTENT
>>
>> *AM_API_RESOURCES*
>> RESOURCE_NAME
>>
>> So the content of INLINE and URL of API documents will be saved in 
>> *AM_API_DOC_META_DATA
>> (*DOC_CONTENT column*) *and content of FILE of API documents will be
>> saved in *AM_API_RESOURCES *which will have a reference in 
>> *AM_API_DOC_META_DATA
>> (*RESOURCE_ID column*)*.
>>
>> Thanks & Regards,
>> Mushthaq
>>
>>
>> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara 
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Here is my take on this. When I originally designed the schema I
 wasn't taking into consideration any of the practical implications
 associated with API resources being saved and retrieved at DB level. 
 But
 now that we are at implementation stage some of these implications are 
 much
 more clearer now.

 The AM_API_RESOURCES is a generic API resource table(For storing
 all file based resources associated with APIs). It will be storing the
 Swagger file, Ballerina file and documentation associated with the API.

 The AM_API_DOC_META_DATA table is specialized to store additional
 meta data only associated with documentation.

 Practically we need to do two calls for document uploads and adding
 meta data because we are dealing with two different content
 types(application/json for meta data and multipart/form-data for the 
 file).

 All files have a name associated with them so it makes sense to
 have the file name in the AM_API_RESOURCES table. I don't think its a 
 good
 idea to have a NULL value in a column that we are going to update 
 later,
 this could lead to all kinds of complications that we will need to 
 handle
 at code level. So its better to have the file name in AM_API_RESOURCES
 where we can ensure that we always have a valid name at the time of 
 upload.
 It is also very easy for us to enforce that a file name for a given 

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Mushthaq Rumy]

+1 for having all API doc related data in a single table and rename the
table as DOCS.

Thanks & Regards,
Mushthaq

On Tue, Oct 23, 2018 at 10:07 AM Uvindra Dias Jayasinha 
wrote:

> @Bhathiya Jayasekara 
> yes, this is also an option. In reality though very few customers upload
> lots of additional docs. We could just rename DOC_META_DATA table to DOCS
> and store the docs in that table itself. So at the very minimum we have a
> swagger and ballerina definition per an API stored in the RESOURCES table.
>
> Can we make a call on this soon? Implementation is getting delayed because
> of this.
>
> On Mon, 22 Oct 2018 at 21:08, Bhathiya Jayasekara 
> wrote:
>
>> This looks ok. Btw, I was wondering if it's a good idea to have all files
>> (swaggers, wsdls, docs etc.) in a single table. Won't that make the table
>> grow faster and make querying slower? How about keeping a separate table
>> for this? Then we can have a foreign key as well.
>>
>> Thanks,
>> Bhathiya
>>
>> On Mon, Oct 22, 2018 at 2:57 PM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> +1, CONTENT  is fine
>>>
>>> On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:
>>>
 Hi Uvindra,

 Please find the data types below

 *AM_API_DOC_META_DATA*
 API_ID (This will be a foreign key referred to AM_API table)
 VARCHAR(255)
 RESOURCE_ID VARCHAR(255)
 DOC_CONTENT VARCHAR(1024)

 *AM_API_RESOURCES*
 RESOURCE_NAME VARCHAR(255)

 And I think we can change it DOC_CONTENT to CONTENT .
 WDYT?

 Thanks & Regards,
 Mushthaq

 On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> HI Mushtaq,
>
> Can you provide the data types of the columns so that this is more
> clear? I believe that DOC_CONTENT should be a VARCHAR, in that case better
> to call it something like SHORT_CONTENT, since this communicates that it 
> is
> meant to share relatively short text values such as URL and inline text.
> The name DOC_CONTENT is misleading and might suggest we can store larger
> documents in this column.
>
> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>
>> Hi All,
>>
>> We had an internal discussion and decided to do some modifications in
>> the DB Schema related to API Docs (AM_API_RESOURCES and
>> AM_API_DOC_META_DATA). We will be removing the foreign key constraint 
>> added
>> to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
>> the primary key of AM_API_RESOURCES which is not a good practice.
>>
>> And the following columns will be added to the respective tables.
>>
>> *AM_API_DOC_META_DATA*
>> API_ID (This will be a foreign key referred to AM_API table)
>> RESOURCE_ID
>> DOC_CONTENT
>>
>> *AM_API_RESOURCES*
>> RESOURCE_NAME
>>
>> So the content of INLINE and URL of API documents will be saved in 
>> *AM_API_DOC_META_DATA
>> (*DOC_CONTENT column*) *and content of FILE of API documents will be
>> saved in *AM_API_RESOURCES *which will have a reference in 
>> *AM_API_DOC_META_DATA
>> (*RESOURCE_ID column*)*.
>>
>> Thanks & Regards,
>> Mushthaq
>>
>>
>> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara 
>> wrote:
>>
>>>
>>>
>>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Here is my take on this. When I originally designed the schema I
 wasn't taking into consideration any of the practical implications
 associated with API resources being saved and retrieved at DB level. 
 But
 now that we are at implementation stage some of these implications are 
 much
 more clearer now.

 The AM_API_RESOURCES is a generic API resource table(For storing
 all file based resources associated with APIs). It will be storing the
 Swagger file, Ballerina file and documentation associated with the API.

 The AM_API_DOC_META_DATA table is specialized to store additional
 meta data only associated with documentation.

 Practically we need to do two calls for document uploads and adding
 meta data because we are dealing with two different content
 types(application/json for meta data and multipart/form-data for the 
 file).

 All files have a name associated with them so it makes sense to
 have the file name in the AM_API_RESOURCES table. I don't think its a 
 good
 idea to have a NULL value in a column that we are going to update 
 later,
 this could lead to all kinds of complications that we will need to 
 handle
 at code level. So its better to have the file name in AM_API_RESOURCES
 where we can ensure that we always have a valid name at the time of 
 upload.
 It is also 

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

@Bhathiya Jayasekara 
yes, this is also an option. In reality though very few customers upload
lots of additional docs. We could just rename DOC_META_DATA table to DOCS
and store the docs in that table itself. So at the very minimum we have a
swagger and ballerina definition per an API stored in the RESOURCES table.

Can we make a call on this soon? Implementation is getting delayed because
of this.

On Mon, 22 Oct 2018 at 21:08, Bhathiya Jayasekara  wrote:

> This looks ok. Btw, I was wondering if it's a good idea to have all files
> (swaggers, wsdls, docs etc.) in a single table. Won't that make the table
> grow faster and make querying slower? How about keeping a separate table
> for this? Then we can have a foreign key as well.
>
> Thanks,
> Bhathiya
>
> On Mon, Oct 22, 2018 at 2:57 PM Uvindra Dias Jayasinha 
> wrote:
>
>> +1, CONTENT  is fine
>>
>> On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:
>>
>>> Hi Uvindra,
>>>
>>> Please find the data types below
>>>
>>> *AM_API_DOC_META_DATA*
>>> API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255)
>>> RESOURCE_ID VARCHAR(255)
>>> DOC_CONTENT VARCHAR(1024)
>>>
>>> *AM_API_RESOURCES*
>>> RESOURCE_NAME VARCHAR(255)
>>>
>>> And I think we can change it DOC_CONTENT to CONTENT .
>>> WDYT?
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>> On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha 
>>> wrote:
>>>
 HI Mushtaq,

 Can you provide the data types of the columns so that this is more
 clear? I believe that DOC_CONTENT should be a VARCHAR, in that case better
 to call it something like SHORT_CONTENT, since this communicates that it is
 meant to share relatively short text values such as URL and inline text.
 The name DOC_CONTENT is misleading and might suggest we can store larger
 documents in this column.

 On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:

> Hi All,
>
> We had an internal discussion and decided to do some modifications in
> the DB Schema related to API Docs (AM_API_RESOURCES and
> AM_API_DOC_META_DATA). We will be removing the foreign key constraint 
> added
> to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
> the primary key of AM_API_RESOURCES which is not a good practice.
>
> And the following columns will be added to the respective tables.
>
> *AM_API_DOC_META_DATA*
> API_ID (This will be a foreign key referred to AM_API table)
> RESOURCE_ID
> DOC_CONTENT
>
> *AM_API_RESOURCES*
> RESOURCE_NAME
>
> So the content of INLINE and URL of API documents will be saved in 
> *AM_API_DOC_META_DATA
> (*DOC_CONTENT column*) *and content of FILE of API documents will be
> saved in *AM_API_RESOURCES *which will have a reference in 
> *AM_API_DOC_META_DATA
> (*RESOURCE_ID column*)*.
>
> Thanks & Regards,
> Mushthaq
>
>
> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara 
> wrote:
>
>>
>>
>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
>> uvin...@wso2.com> wrote:
>>
>>> Here is my take on this. When I originally designed the schema I
>>> wasn't taking into consideration any of the practical implications
>>> associated with API resources being saved and retrieved at DB level. But
>>> now that we are at implementation stage some of these implications are 
>>> much
>>> more clearer now.
>>>
>>> The AM_API_RESOURCES is a generic API resource table(For storing all
>>> file based resources associated with APIs). It will be storing the 
>>> Swagger
>>> file, Ballerina file and documentation associated with the API.
>>>
>>> The AM_API_DOC_META_DATA table is specialized to store additional
>>> meta data only associated with documentation.
>>>
>>> Practically we need to do two calls for document uploads and adding
>>> meta data because we are dealing with two different content
>>> types(application/json for meta data and multipart/form-data for the 
>>> file).
>>>
>>> All files have a name associated with them so it makes sense to have
>>> the file name in the AM_API_RESOURCES table. I don't think its a good 
>>> idea
>>> to have a NULL value in a column that we are going to update later, this
>>> could lead to all kinds of complications that we will need to handle at
>>> code level. So its better to have the file name in AM_API_RESOURCES 
>>> where
>>> we can ensure that we always have a valid name at the time of upload. 
>>> It is
>>> also very easy for us to enforce that a file name for a given type does 
>>> not
>>> get duplicated with a table level constraint if we go with this option.
>>>
>>> Joining between two tables like this in case we need to get the file
>>> name is trivial so I don't think we should let that affect us coming up
>>> with the best possible 

Re: [Dev] [IS] InCommon Federation Compliance for WSO2IS - UI Component

[Sahan Gunathilaka]

Hi Johann,

Please note that there are some modifications to be done on this. Also, if
the placement is not matching here, it can go under the "Configure" tab
(since the overall process is to configure SPs and IdPs).
I think that your point is fair about avoiding InCommon logo and I will
consider that too.
I will update this soon and thank you very much for your feedback.

Best Regards!


On Fri, Oct 19, 2018 at 4:05 PM Johann Nallathamby  wrote:

> Hi Sahan,
>
> Two concerns here:
> 1. Is the placement of the feature in the menu correct?
> 2. I don't know if it was intensional, but isn't it better to avoid
> InCommon logos and only label it using standard federation terminology?
> Because we haven't done it like that so far for other profiles such as
> eIDAS. But again I don't know if this is intensional to get traction to the
> product.
>
> Regards,
> Johann.
>
> On Wed, Sep 26, 2018 at 8:26 AM Sahan Gunathilaka  wrote:
>
>> Hi All,
>> One of the major requirements to comply WSO2 IS with InCommon Federation
>> is to support *auto refreshment* of metadata of participating Service
>> Providers and Identity Providers at IS. Following is the designed UI to
>> provide this requirement.
>>
>> [image: Screenshot_2018-09-26 WSO2 Management Console.png]
>>
>> *"Enable Auto Refresh*" check box and "*Refresh Time*" drop box can be
>> set to automate the refreshing cycle. All service providers' and identity
>> providers' configurations will be updated according to them after clicking
>> on "*Save*" button.
>>
>> "*Force Refresh*" button lets users to refresh metadata instantly based
>> on the latest update of metadata file at the InCommon Federation.
>>
>> "*Clear All*" button will remove all the configured data and result "0"
>> for both "Total Service Providers" and "Total Identity Providers" in the
>> table.
>>
>> If you have any suggestion on this, please let me know.
>>
>> Thank you!
>> Best Regards!
>>
>> --
>> *Sahan Gunathilaka*
>> Intern - Software Engineering
>> *WSO2*
>> mobile:  +94776343266
>>
>> [image: http://wso2.com/signature]
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
>
> *Johann Dilantha Nallathamby*
> Senior Lead Solutions Engineer
> WSO2, Inc.
> lean.enterprise.middleware
>
> Mobile: *+94 77 7776950*
> LinkedIn: *http://www.linkedin.com/in/johann-nallathamby
> *
> Medium: *https://medium.com/@johann_nallathamby
> *
> Twitter: *@dj_nallaa*
>


-- 
*Sahan Gunathilaka*
Intern - Software Engineering
*WSO2*
mobile:  +94776343266

[image: http://wso2.com/signature]
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Role assignment without provisioning the user

[Rajith Siriwardena]

Hi team,

I'm using a custom federated authenticator, which authenticates the user
against 3rd party API. What I would like to know is that, whether we will
be able to assign roles to it without provisioning the user to the user
store.

Thanks,
Rajith


-- 
*Rajith Siriwardana*
WSO2 Inc. | http://wso2.com
*lean. enterprise. middleware*

---
*https://home.apache.org/~siriwardana
*



Disclaimer: This communication may contain privileged or other confidential
information and is intended exclusively for the addressee/s. If you are not
the intended recipient/s, or believe that you may have received this
communication in error, please reply to the sender indicating that fact and
delete the copy you received and in addition, you should not print, copy,
re-transmit, disseminate, or otherwise use the information contained in
this communication. Internet communications cannot be guaranteed to be
timely, secure, error or virus-free. The sender does not accept liability
for any errors or omissions.
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Bhathiya Jayasekara]

This looks ok. Btw, I was wondering if it's a good idea to have all files
(swaggers, wsdls, docs etc.) in a single table. Won't that make the table
grow faster and make querying slower? How about keeping a separate table
for this? Then we can have a foreign key as well.

Thanks,
Bhathiya

On Mon, Oct 22, 2018 at 2:57 PM Uvindra Dias Jayasinha 
wrote:

> +1, CONTENT  is fine
>
> On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:
>
>> Hi Uvindra,
>>
>> Please find the data types below
>>
>> *AM_API_DOC_META_DATA*
>> API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255)
>> RESOURCE_ID VARCHAR(255)
>> DOC_CONTENT VARCHAR(1024)
>>
>> *AM_API_RESOURCES*
>> RESOURCE_NAME VARCHAR(255)
>>
>> And I think we can change it DOC_CONTENT to CONTENT .
>> WDYT?
>>
>> Thanks & Regards,
>> Mushthaq
>>
>> On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> HI Mushtaq,
>>>
>>> Can you provide the data types of the columns so that this is more
>>> clear? I believe that DOC_CONTENT should be a VARCHAR, in that case better
>>> to call it something like SHORT_CONTENT, since this communicates that it is
>>> meant to share relatively short text values such as URL and inline text.
>>> The name DOC_CONTENT is misleading and might suggest we can store larger
>>> documents in this column.
>>>
>>> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>>>
 Hi All,

 We had an internal discussion and decided to do some modifications in
 the DB Schema related to API Docs (AM_API_RESOURCES and
 AM_API_DOC_META_DATA). We will be removing the foreign key constraint added
 to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
 the primary key of AM_API_RESOURCES which is not a good practice.

 And the following columns will be added to the respective tables.

 *AM_API_DOC_META_DATA*
 API_ID (This will be a foreign key referred to AM_API table)
 RESOURCE_ID
 DOC_CONTENT

 *AM_API_RESOURCES*
 RESOURCE_NAME

 So the content of INLINE and URL of API documents will be saved in 
 *AM_API_DOC_META_DATA
 (*DOC_CONTENT column*) *and content of FILE of API documents will be
 saved in *AM_API_RESOURCES *which will have a reference in 
 *AM_API_DOC_META_DATA
 (*RESOURCE_ID column*)*.

 Thanks & Regards,
 Mushthaq


 On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:

>
>
> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
> uvin...@wso2.com> wrote:
>
>> Here is my take on this. When I originally designed the schema I
>> wasn't taking into consideration any of the practical implications
>> associated with API resources being saved and retrieved at DB level. But
>> now that we are at implementation stage some of these implications are 
>> much
>> more clearer now.
>>
>> The AM_API_RESOURCES is a generic API resource table(For storing all
>> file based resources associated with APIs). It will be storing the 
>> Swagger
>> file, Ballerina file and documentation associated with the API.
>>
>> The AM_API_DOC_META_DATA table is specialized to store additional
>> meta data only associated with documentation.
>>
>> Practically we need to do two calls for document uploads and adding
>> meta data because we are dealing with two different content
>> types(application/json for meta data and multipart/form-data for the 
>> file).
>>
>> All files have a name associated with them so it makes sense to have
>> the file name in the AM_API_RESOURCES table. I don't think its a good 
>> idea
>> to have a NULL value in a column that we are going to update later, this
>> could lead to all kinds of complications that we will need to handle at
>> code level. So its better to have the file name in AM_API_RESOURCES where
>> we can ensure that we always have a valid name at the time of upload. It 
>> is
>> also very easy for us to enforce that a file name for a given type does 
>> not
>> get duplicated with a table level constraint if we go with this option.
>>
>> Joining between two tables like this in case we need to get the file
>> name is trivial so I don't think we should let that affect us coming up
>> with the best possible solution.
>>
> +1 it's a not good practice to add record which will update from null
> to some value cause of update going for another table.
>
>>
>> So Im +1 for option 2. WDYT?
>>
>> On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy 
>> wrote:
>>
>>> Adding @dev-wso2 
>>>
>>> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:
>>>
 Please discuss technical problems externally.

 On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy 
 wrote:

> Hi All,
>
> While I was implementing the view page for API 

Re: [Dev] Getting Properties dynamically from registry into

[Shakila Sasikaran]

Hi Aman,

Please find the sample below.



Thanks

On Mon, Oct 22, 2018 at 2:59 PM Aman Singh  wrote:

> Hi Shakila,
>
> When I try to get properties which I have stored in gov/registry in XML ia
> below code I am successfully able to do so:-
>
> 
>  expression="get-property('registry', 'gov:/MyFolder/Entries.xml')"
> name="localProperties" scope="default" type="OM" xmlns:ns="
> http://org.apache.synapse/xsd"/>
> expression="$ctx:localProperties//UserNameIs" name="User" scope="default"
> type="STRING"/>
> 
>
> But If I try to get it via VFS File dynamically from registry then it
> fails to ,  below is sample proxy :-
>
> http://ws.apache.org/ns/synapse;>
> 
> 
> 
> 
> 
>
> 
> 
>
> 
> 
> 
>  name="transport.vfs.Streaming">{ctx:StreamingMode}
>  name="transport.PollInterval">{ctx:PollingInterval}
> {ctx:FileUri}
> 
>
> How can I refer to my registry dynamically in  .Can you help me
> in modifying what I am doing wrong.
>
> Thank you,
> Aman
>


-- 
Shakila Sasikaran
Software Engineer
Mobile :+94 (0) 77 526 6848
shak...@wso2.com
WSO2, Inc.
lean . enterprise . middleware
http://www.wso2.com/
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

+1, CONTENT  is fine

On Mon, 22 Oct 2018 at 14:45, Mushthaq Rumy  wrote:

> Hi Uvindra,
>
> Please find the data types below
>
> *AM_API_DOC_META_DATA*
> API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255)
> RESOURCE_ID VARCHAR(255)
> DOC_CONTENT VARCHAR(1024)
>
> *AM_API_RESOURCES*
> RESOURCE_NAME VARCHAR(255)
>
> And I think we can change it DOC_CONTENT to CONTENT .
> WDYT?
>
> Thanks & Regards,
> Mushthaq
>
> On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha 
> wrote:
>
>> HI Mushtaq,
>>
>> Can you provide the data types of the columns so that this is more clear?
>> I believe that DOC_CONTENT should be a VARCHAR, in that case better to call
>> it something like SHORT_CONTENT, since this communicates that it is meant
>> to share relatively short text values such as URL and inline text. The name
>> DOC_CONTENT is misleading and might suggest we can store larger documents
>> in this column.
>>
>> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>>
>>> Hi All,
>>>
>>> We had an internal discussion and decided to do some modifications in
>>> the DB Schema related to API Docs (AM_API_RESOURCES and
>>> AM_API_DOC_META_DATA). We will be removing the foreign key constraint added
>>> to the  AM_API_DOC_META_DATA table as it it has a primary key referred to
>>> the primary key of AM_API_RESOURCES which is not a good practice.
>>>
>>> And the following columns will be added to the respective tables.
>>>
>>> *AM_API_DOC_META_DATA*
>>> API_ID (This will be a foreign key referred to AM_API table)
>>> RESOURCE_ID
>>> DOC_CONTENT
>>>
>>> *AM_API_RESOURCES*
>>> RESOURCE_NAME
>>>
>>> So the content of INLINE and URL of API documents will be saved in 
>>> *AM_API_DOC_META_DATA
>>> (*DOC_CONTENT column*) *and content of FILE of API documents will be
>>> saved in *AM_API_RESOURCES *which will have a reference in 
>>> *AM_API_DOC_META_DATA
>>> (*RESOURCE_ID column*)*.
>>>
>>> Thanks & Regards,
>>> Mushthaq
>>>
>>>
>>> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:
>>>


 On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
 uvin...@wso2.com> wrote:

> Here is my take on this. When I originally designed the schema I
> wasn't taking into consideration any of the practical implications
> associated with API resources being saved and retrieved at DB level. But
> now that we are at implementation stage some of these implications are 
> much
> more clearer now.
>
> The AM_API_RESOURCES is a generic API resource table(For storing all
> file based resources associated with APIs). It will be storing the Swagger
> file, Ballerina file and documentation associated with the API.
>
> The AM_API_DOC_META_DATA table is specialized to store additional meta
> data only associated with documentation.
>
> Practically we need to do two calls for document uploads and adding
> meta data because we are dealing with two different content
> types(application/json for meta data and multipart/form-data for the 
> file).
>
> All files have a name associated with them so it makes sense to have
> the file name in the AM_API_RESOURCES table. I don't think its a good idea
> to have a NULL value in a column that we are going to update later, this
> could lead to all kinds of complications that we will need to handle at
> code level. So its better to have the file name in AM_API_RESOURCES where
> we can ensure that we always have a valid name at the time of upload. It 
> is
> also very easy for us to enforce that a file name for a given type does 
> not
> get duplicated with a table level constraint if we go with this option.
>
> Joining between two tables like this in case we need to get the file
> name is trivial so I don't think we should let that affect us coming up
> with the best possible solution.
>
 +1 it's a not good practice to add record which will update from null
 to some value cause of update going for another table.

>
> So Im +1 for option 2. WDYT?
>
> On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy  wrote:
>
>> Adding @dev-wso2 
>>
>> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:
>>
>>> Please discuss technical problems externally.
>>>
>>> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy 
>>> wrote:
>>>
 Hi All,

 While I was implementing the view page for API document (File) I
 came across an issue where we get the file name as null when using the
 micro-service to get the content of the the API document.
 While analyzing, when adding a file as an API document, I found out
 that first we save only the doc metadata  and then we save the file 
 content
 using a second call.

 After analyzing the DB scripts I figured out that the fileName is
 stored in AM_API_DOC_META_DATA table and the 

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Mushthaq Rumy]

Hi Uvindra,

Please find the data types below

*AM_API_DOC_META_DATA*
API_ID (This will be a foreign key referred to AM_API table) VARCHAR(255)
RESOURCE_ID VARCHAR(255)
DOC_CONTENT VARCHAR(1024)

*AM_API_RESOURCES*
RESOURCE_NAME VARCHAR(255)

And I think we can change it DOC_CONTENT to CONTENT .
WDYT?

Thanks & Regards,
Mushthaq

On Mon, Oct 22, 2018 at 2:35 PM Uvindra Dias Jayasinha 
wrote:

> HI Mushtaq,
>
> Can you provide the data types of the columns so that this is more clear?
> I believe that DOC_CONTENT should be a VARCHAR, in that case better to call
> it something like SHORT_CONTENT, since this communicates that it is meant
> to share relatively short text values such as URL and inline text. The name
> DOC_CONTENT is misleading and might suggest we can store larger documents
> in this column.
>
> On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:
>
>> Hi All,
>>
>> We had an internal discussion and decided to do some modifications in the
>> DB Schema related to API Docs (AM_API_RESOURCES and AM_API_DOC_META_DATA).
>> We will be removing the foreign key constraint added to the
>> AM_API_DOC_META_DATA table as it it has a primary key referred to the
>> primary key of AM_API_RESOURCES which is not a good practice.
>>
>> And the following columns will be added to the respective tables.
>>
>> *AM_API_DOC_META_DATA*
>> API_ID (This will be a foreign key referred to AM_API table)
>> RESOURCE_ID
>> DOC_CONTENT
>>
>> *AM_API_RESOURCES*
>> RESOURCE_NAME
>>
>> So the content of INLINE and URL of API documents will be saved in 
>> *AM_API_DOC_META_DATA
>> (*DOC_CONTENT column*) *and content of FILE of API documents will be
>> saved in *AM_API_RESOURCES *which will have a reference in 
>> *AM_API_DOC_META_DATA
>> (*RESOURCE_ID column*)*.
>>
>> Thanks & Regards,
>> Mushthaq
>>
>>
>> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:
>>
>>>
>>>
>>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha <
>>> uvin...@wso2.com> wrote:
>>>
 Here is my take on this. When I originally designed the schema I wasn't
 taking into consideration any of the practical implications associated with
 API resources being saved and retrieved at DB level. But now that we are at
 implementation stage some of these implications are much more clearer now.

 The AM_API_RESOURCES is a generic API resource table(For storing all
 file based resources associated with APIs). It will be storing the Swagger
 file, Ballerina file and documentation associated with the API.

 The AM_API_DOC_META_DATA table is specialized to store additional meta
 data only associated with documentation.

 Practically we need to do two calls for document uploads and adding
 meta data because we are dealing with two different content
 types(application/json for meta data and multipart/form-data for the file).

 All files have a name associated with them so it makes sense to have
 the file name in the AM_API_RESOURCES table. I don't think its a good idea
 to have a NULL value in a column that we are going to update later, this
 could lead to all kinds of complications that we will need to handle at
 code level. So its better to have the file name in AM_API_RESOURCES where
 we can ensure that we always have a valid name at the time of upload. It is
 also very easy for us to enforce that a file name for a given type does not
 get duplicated with a table level constraint if we go with this option.

 Joining between two tables like this in case we need to get the file
 name is trivial so I don't think we should let that affect us coming up
 with the best possible solution.

>>> +1 it's a not good practice to add record which will update from null to
>>> some value cause of update going for another table.
>>>

 So Im +1 for option 2. WDYT?

 On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy  wrote:

> Adding @dev-wso2 
>
> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:
>
>> Please discuss technical problems externally.
>>
>> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy 
>> wrote:
>>
>>> Hi All,
>>>
>>> While I was implementing the view page for API document (File) I
>>> came across an issue where we get the file name as null when using the
>>> micro-service to get the content of the the API document.
>>> While analyzing, when adding a file as an API document, I found out
>>> that first we save only the doc metadata  and then we save the file 
>>> content
>>> using a second call.
>>>
>>> After analyzing the DB scripts I figured out that the fileName is
>>> stored in AM_API_DOC_META_DATA table and the content is stored in
>>> AM_API_RESOURCES. So during the first call we do not have the file name 
>>> and
>>> it is saved as null. During the second call the fileName is passed to 
>>> the
>>> micro-service but it is not stored 

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Uvindra Dias Jayasinha]

HI Mushtaq,

Can you provide the data types of the columns so that this is more clear? I
believe that DOC_CONTENT should be a VARCHAR, in that case better to call
it something like SHORT_CONTENT, since this communicates that it is meant
to share relatively short text values such as URL and inline text. The name
DOC_CONTENT is misleading and might suggest we can store larger documents
in this column.

On Mon, 22 Oct 2018 at 14:02, Mushthaq Rumy  wrote:

> Hi All,
>
> We had an internal discussion and decided to do some modifications in the
> DB Schema related to API Docs (AM_API_RESOURCES and AM_API_DOC_META_DATA).
> We will be removing the foreign key constraint added to the
> AM_API_DOC_META_DATA table as it it has a primary key referred to the
> primary key of AM_API_RESOURCES which is not a good practice.
>
> And the following columns will be added to the respective tables.
>
> *AM_API_DOC_META_DATA*
> API_ID (This will be a foreign key referred to AM_API table)
> RESOURCE_ID
> DOC_CONTENT
>
> *AM_API_RESOURCES*
> RESOURCE_NAME
>
> So the content of INLINE and URL of API documents will be saved in 
> *AM_API_DOC_META_DATA
> (*DOC_CONTENT column*) *and content of FILE of API documents will be
> saved in *AM_API_RESOURCES *which will have a reference in 
> *AM_API_DOC_META_DATA
> (*RESOURCE_ID column*)*.
>
> Thanks & Regards,
> Mushthaq
>
>
> On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:
>
>>
>>
>> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha 
>> wrote:
>>
>>> Here is my take on this. When I originally designed the schema I wasn't
>>> taking into consideration any of the practical implications associated with
>>> API resources being saved and retrieved at DB level. But now that we are at
>>> implementation stage some of these implications are much more clearer now.
>>>
>>> The AM_API_RESOURCES is a generic API resource table(For storing all
>>> file based resources associated with APIs). It will be storing the Swagger
>>> file, Ballerina file and documentation associated with the API.
>>>
>>> The AM_API_DOC_META_DATA table is specialized to store additional meta
>>> data only associated with documentation.
>>>
>>> Practically we need to do two calls for document uploads and adding meta
>>> data because we are dealing with two different content
>>> types(application/json for meta data and multipart/form-data for the file).
>>>
>>> All files have a name associated with them so it makes sense to have the
>>> file name in the AM_API_RESOURCES table. I don't think its a good idea to
>>> have a NULL value in a column that we are going to update later, this could
>>> lead to all kinds of complications that we will need to handle at code
>>> level. So its better to have the file name in AM_API_RESOURCES where we can
>>> ensure that we always have a valid name at the time of upload. It is also
>>> very easy for us to enforce that a file name for a given type does not get
>>> duplicated with a table level constraint if we go with this option.
>>>
>>> Joining between two tables like this in case we need to get the file
>>> name is trivial so I don't think we should let that affect us coming up
>>> with the best possible solution.
>>>
>> +1 it's a not good practice to add record which will update from null to
>> some value cause of update going for another table.
>>
>>>
>>> So Im +1 for option 2. WDYT?
>>>
>>> On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy  wrote:
>>>
 Adding @dev-wso2 

 On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:

> Please discuss technical problems externally.
>
> On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy 
> wrote:
>
>> Hi All,
>>
>> While I was implementing the view page for API document (File) I came
>> across an issue where we get the file name as null when using the
>> micro-service to get the content of the the API document.
>> While analyzing, when adding a file as an API document, I found out
>> that first we save only the doc metadata  and then we save the file 
>> content
>> using a second call.
>>
>> After analyzing the DB scripts I figured out that the fileName is
>> stored in AM_API_DOC_META_DATA table and the content is stored in
>> AM_API_RESOURCES. So during the first call we do not have the file name 
>> and
>> it is saved as null. During the second call the fileName is passed to the
>> micro-service but it is not stored anywhere. Hence, the fileName is null
>> when we get the content of the file. So to solve this issue, I thought of
>> two solutions.
>>
>> 1. During the second call while adding a file document for API as we
>> get the FileName to the micro-service we can retrieve the document 
>> metadata
>> using the documentId and update the fileName apart from saving the 
>> content.
>> Hence, it will be available when retrieving the content.
>>
>> 2. We can change the fileName field from AM_API_DOC_META_DATA 

Re: [Dev] Issue in getting the fileName when getting the API Documents content via REST API

[Mushthaq Rumy]

Hi All,

We had an internal discussion and decided to do some modifications in the
DB Schema related to API Docs (AM_API_RESOURCES and AM_API_DOC_META_DATA).
We will be removing the foreign key constraint added to the
AM_API_DOC_META_DATA table as it it has a primary key referred to the
primary key of AM_API_RESOURCES which is not a good practice.

And the following columns will be added to the respective tables.

*AM_API_DOC_META_DATA*
API_ID (This will be a foreign key referred to AM_API table)
RESOURCE_ID
DOC_CONTENT

*AM_API_RESOURCES*
RESOURCE_NAME

So the content of INLINE and URL of API documents will be saved in
*AM_API_DOC_META_DATA
(*DOC_CONTENT column*) *and content of FILE of API documents will be saved
in *AM_API_RESOURCES *which will have a reference in *AM_API_DOC_META_DATA
(*RESOURCE_ID column*)*.

Thanks & Regards,
Mushthaq


On Fri, Oct 19, 2018 at 9:23 PM Harsha Kumara  wrote:

>
>
> On Fri, Oct 19, 2018 at 10:30 AM Uvindra Dias Jayasinha 
> wrote:
>
>> Here is my take on this. When I originally designed the schema I wasn't
>> taking into consideration any of the practical implications associated with
>> API resources being saved and retrieved at DB level. But now that we are at
>> implementation stage some of these implications are much more clearer now.
>>
>> The AM_API_RESOURCES is a generic API resource table(For storing all file
>> based resources associated with APIs). It will be storing the Swagger file,
>> Ballerina file and documentation associated with the API.
>>
>> The AM_API_DOC_META_DATA table is specialized to store additional meta
>> data only associated with documentation.
>>
>> Practically we need to do two calls for document uploads and adding meta
>> data because we are dealing with two different content
>> types(application/json for meta data and multipart/form-data for the file).
>>
>> All files have a name associated with them so it makes sense to have the
>> file name in the AM_API_RESOURCES table. I don't think its a good idea to
>> have a NULL value in a column that we are going to update later, this could
>> lead to all kinds of complications that we will need to handle at code
>> level. So its better to have the file name in AM_API_RESOURCES where we can
>> ensure that we always have a valid name at the time of upload. It is also
>> very easy for us to enforce that a file name for a given type does not get
>> duplicated with a table level constraint if we go with this option.
>>
>> Joining between two tables like this in case we need to get the file name
>> is trivial so I don't think we should let that affect us coming up with the
>> best possible solution.
>>
> +1 it's a not good practice to add record which will update from null to
> some value cause of update going for another table.
>
>>
>> So Im +1 for option 2. WDYT?
>>
>> On Thu, 18 Oct 2018 at 17:31, Mushthaq Rumy  wrote:
>>
>>> Adding @dev-wso2 
>>>
>>> On Thu, Oct 18, 2018 at 5:25 PM Nuwan Dias  wrote:
>>>
 Please discuss technical problems externally.

 On Thu, Oct 18, 2018 at 3:44 PM Mushthaq Rumy 
 wrote:

> Hi All,
>
> While I was implementing the view page for API document (File) I came
> across an issue where we get the file name as null when using the
> micro-service to get the content of the the API document.
> While analyzing, when adding a file as an API document, I found out
> that first we save only the doc metadata  and then we save the file 
> content
> using a second call.
>
> After analyzing the DB scripts I figured out that the fileName is
> stored in AM_API_DOC_META_DATA table and the content is stored in
> AM_API_RESOURCES. So during the first call we do not have the file name 
> and
> it is saved as null. During the second call the fileName is passed to the
> micro-service but it is not stored anywhere. Hence, the fileName is null
> when we get the content of the file. So to solve this issue, I thought of
> two solutions.
>
> 1. During the second call while adding a file document for API as we
> get the FileName to the micro-service we can retrieve the document 
> metadata
> using the documentId and update the fileName apart from saving the 
> content.
> Hence, it will be available when retrieving the content.
>
> 2. We can change the fileName field from AM_API_DOC_META_DATA to
> AM_API_RESOURCES as the content of the document is stored in this table.
> And while saving the content we can save it with the fileName. Hence, it
> will be available when retrieving the content.
>
> IMO as option 1 will have more DB calls, option 2 would be the
> preferred solution.
>
> Appreciate your valuable inputs.
>
> Thanks & Regards,
> Mushthaq
> --
> Mushthaq Rumy
> *Senior Software Engineer*
> Mobile : +94 (0) 779 492140
> Email : musht...@wso2.com
> WSO2, Inc.; http://wso2.com/
> lean . 

Re: [Dev] [APIM 2.5.0] API Gateways not showing in store console

[Godwin Shrimal]

Created [1] https://github.com/wso2/product-apim/issues/3880 to track the
issue.

[1] https://github.com/wso2/product-apim/issues/3880

Thanks
Godwin

On Sun, Oct 21, 2018 at 3:53 PM Godwin Shrimal  wrote:

> Hi Tharindu,
>
> Yes. This is a distributed setup and it is having correct configurations
> in Pub/Store node. APIs are getting published correctly for sandbox and
> production gateways. Here problem is in the  swagger console, when we have
> two gateways in different types (as "production" and "sandbox"), its not
> allowing to select API Gateway and when we select Sandbox key request
> always going to production gateway endpoint.
>
> Thanks
> Godwin
>
> On Sat, Oct 20, 2018 at 11:21 AM Tharindu Dharmarathna 
> wrote:
>
>> Hi Godwin,
>>
>> Is this a distributed setup ?, If so please check gateway configuration
>> under store node, as we use those configurations to call endpoints, and
>> also if you correctly publish APIs as sandbox and production, You'll not be
>> able to invoke APIs in production node as we not defining the sandbox
>> endpoint.
>>
>> On Sat, Oct 20, 2018 at 12:01 PM Godwin Shrimal  wrote:
>>
>>> Hi Nuwan,
>>>
>>> I am using two gateways with one is having "production" and other one
>>> having "sandbox" type. According to the offline chat had with Thilini, it
>>> is showing drop-down only if there are more than one gateways from *one
>>> gateway type*. So since we can't select sandbox endpoint, even we
>>> select sandbox key its calling production gateway endpoint.
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Sat, Oct 20, 2018 at 3:53 AM Thilini Shanika 
>>> wrote:
>>>
 Hi Godwin,

 Further, if you don't have more than one gateway environments defined
 under a given type (production, sandbox, or hybrid), API Gateway drop-down
 won't be showing up in API console, since you don't have multiple gateway
 endpoints to select in the drop down. That is by design and not a bug.

 On Sat, Oct 20, 2018 at 5:16 AM Nuwan Dias  wrote:

> Valid types are "production", "sandbox" and "hybrid". Are you using
> one of these or something called "production and sandbox"?
>
> On Fri, Oct 19, 2018 at 9:11 PM Harsha Kumara 
> wrote:
>
>> @Thilini Shanika 
>>
>> On Fri, Oct 19, 2018 at 3:20 PM Godwin Shrimal 
>> wrote:
>>
>>> Hi APIM Team,
>>>
>>> We can't see gateways in API Store Console when we use type as
>>> production and sandbox. If we use both gateways as hybrid then I can see
>>> the API Gateways in the swagger console.
>>> Is it a known issue?
>>>
>>> Thanks
>>> Godwin
>>> --
>>> *Godwin Amila Shrimal*
>>> Associate Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94761124419*
>>> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/
>>> *
>>> twitter: https://twitter.com/godwinamila
>>> 
>>>
>>
>>
>> --
>>
>> *Harsha Kumara*
>>
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Email: hars...@wso2.coim
>> Blog: harshcreationz.blogspot.com
>>
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
> *Nuwan Dias* | Director | WSO2 Inc.
> (m) +94 777 775 729 | (e) nuw...@wso2.com
> [image: Signature.jpg]
>


 --
 Thilini Shanika
 Associate Technical Lead
 WSO2, Inc.; http://wso2.com
 20, Palmgrove Avenue, Colombo 3

 E-mail: tgtshan...@gmail.com


>>>
>>> --
>>> *Godwin Amila Shrimal*
>>> Associate Technical Lead
>>> WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: *+94761124419*
>>> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/
>>> *
>>> twitter: https://twitter.com/godwinamila
>>> 
>>> ___
>>> Dev mailing list
>>> Dev@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>
>>
>> --
>>
>> *Tharindu Dharmarathna*Associate Technical Lead
>> WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: *+94779109091*
>>
>
>
> --
> *Godwin Amila Shrimal*
> Associate Technical Lead
> WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: *+94761124419*
> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/
> *
> twitter: https://twitter.com/godwinamila
> 
>


-- 
*Godwin Amila Shrimal*
Associate Technical Lead
WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: *+94761124419*
linkedin: