Re: [Architecture] API Manager REST API with tier grouping feature

[Frank Leymann]

Hi Malintha,

sorry for the late response.  A post is used on a collection to add a new
resource to this collection. While /tiers is for sure a collection, the
question is whether /tiers/{tier-level} is a collection too.  Even if it
is, it sounds a bit strange to me to add a tier to a collection that
corresponds to a tier-level.

Instead, I assume that the data model of a tier contains more than just a
tier-level attribute, right?  If tier-level is one of many properties of a
tier, I suggest that we POST to /tier...


Best regards,
Frank

2015-12-01 13:10 GMT+01:00 Malintha Amarasinghe :

> Hi Nuwan,
>
> Thanks for the clarification.
>
> Hi Frank,
>
> Yes, would that need to be changed for POST /tiers/{tier-level}? Or shall
> we keep the previous one (/tiers ) only for POST and identify the tier
> level from the request body?
>
> Thanks.
>
>
> On Tue, Dec 1, 2015 at 5:32 PM, Frank Leymann  wrote:
>
>> Just to double-check:  but we still have a POST /tiers to add a new tier
>> to the collection, right?
>>
>>
>> Best regards,
>> Frank
>>
>> 2015-12-01 11:50 GMT+01:00 Nuwan Dias :
>>
>>> I think the group param should be mandatory. Therefore there will not be
>>> a GET /tiers, but instead a GET /tiers/{level} only.
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe >> > wrote:
>>>
 Hi Nuwan, Sanjeewa and Joe,

 Thanks a lot for all the suggestions.

 I have a small doubt for using the group as part of the path.

 Lets say we use GET /tiers/api/{tier-id} to get a single API tier by
 its id (actually Name). Then, are we exposing the resource /tiers alone
 too?  If we do, are we returning the tier groups for GET /tiers? In this
 case, returning tiers will not be appropriate IMO as the immediate
 sub-resource is not a tier, but a tier type. Or can we just make the group
 parameter mandatory?

 Thank you.
 Malintha

 On Tue, Dec 1, 2015 at 11:54 AM, Nuwan Dias  wrote:

>
>
> On Tue, Dec 1, 2015 at 11:21 AM, Joseph Fonseka 
> wrote:
>
>> IMO if we have multiple tier files a path param would be more
>> suitable. If we have only one tier file and the group(level) is an
>> attribute then we could have use a query param.
>>
>> Any specific reason to have a tier file for each level ? Rather than
>> having an attribute to group tiers. Or for each tier specifying 
>> application,
>> API and resource level throttling separately.
>>
>
> Having everything on a single file makes the tier definitions very
> noisy. Having it separately makes it very clean and easy to manage.
>
> For example, the API tiers now have attributes related to billing
> information. These won't make sense for Application level and Resource
> level tiers. So having them in separate files makes sense IMO. In addition
> to that having them separately allows us to perform access control for
> those resources as well.
>
>>
>> Thanks
>> Jo
>>
>>
>>
>>
>>
>> On Tue, Dec 1, 2015 at 10:06 AM, Sanjeewa Malalgoda <
>> sanje...@wso2.com> wrote:
>>
>>> What we agreed last week is let users to fetch tiers based on type,
>>> It can be either path param like mentioned above or query param
>>> tiers?tier-level=application.
>>>
>>> Existing users will get same set of tiers for application, API and
>>> resource.
>>> But new deployments and people who willing to have different levels
>>> can change them as per requirements.
>>> Having same names in application, API and resource level with
>>> different unit time and count may be bit confusing IMO.
>>> Still nothing will break as we return requested tier list.
>>>
>>> Thanks,
>>> sanjeewa.
>>>
>>>
>>>
>>> On Tue, Dec 1, 2015 at 8:41 AM, Nuwan Dias  wrote:
>>>
 @Sanjeewa, users migrating from older versions of API Manager will
 have their tiers duplicated across all levels. And its not wrong for 
 users
 to have the same tier across all levels as well. Therefore having 
 duplicate
 tier names in different levels is valid scenario.

 @Jo, yes there's a tier.xml file per group.

 @Malintha, I think the resource url should be
 /tiers/{level}/{tier-id}. Ex: GET /tiers/application/Gold.

 Thanks,
 NuwanD.


 On Tue, Dec 1, 2015 at 7:51 AM, Joseph Fonseka 
 wrote:

> Hi Malintha
>
> Do we have multiple tier.xml files per group ?
>
> On Tue, Dec 1, 2015 at 7:41 AM, Sanjeewa Malalgoda <
> sanje...@wso2.com> wrote:
>
>>
>>
>> On Mon, Nov 30, 2015 at 11:05 PM, Malintha Amarasinghe <
>> malint...@wso2.com> wrote:
>>
>>> Hi All,
>>>
>>> With the new

Re: [Architecture] [ESB] Adding features for VFS inbound(include option copy and leave as it is) and ESB polling inbound(support with cron).

[Kalyani Yogeswaranathan]

Hi Kirishanthy,

These resources may help you to get some knowledge about VFS Transport[1]
and File inbound[2].

   1. https://docs.wso2.com/display/ESB490/VFS+Transport
   2. https://docs.wso2.com/display/ESB490/File+Inbound+Protocol
   3.
   
https://github.com/wso2/carbon-mediation/tree/master/components/inbound-endpoints

Thank you.

On Fri, Dec 11, 2015 at 11:49 AM, Jagath Sisirakumara Ariyarathne <
jaga...@wso2.com> wrote:

> Hi,
>
> To get the input for polling interval/cron configuration, how about using
> a toggle button like in Scheduled Tasks.
>
> [image: Inline image 1]
>
> In this case, we can set interval as default selection. Based on the
> selection, you can use required implementation.
>
> Thanks.
>
> On Fri, Dec 11, 2015 at 10:56 AM, Kirishanthy Tharmalingam <
> kirishan...@wso2.com> wrote:
>
>> Hi all ,
>>
>> Now I'm working on following improvement in the VFS inbound and ESB
>> polling inbound.
>>
>>1. For VFS inbound we only have the option to delete or move file
>>after processed or after error. Need to give the options copy and  leave 
>> as
>>it is.
>>2. Current ESB polling inbound only support interval. But we need to
>>have the ability to schedule it using cron expressions.
>>
>> In first case leave as it is the good option because we can used the same
>> file again and again.
>> In the copy option we copy the same file again and again, so If the file
>> is already exist in the destination directory delete the file and copy the
>> file again.
>> use case of copy option is we can update the content of the file(because
>> it is exist in the source directory), then the next polling we can copy the
>> updated file to the destination directory.(because delete the existing file
>> in the destination directory and copy the updated file).  Is there any
>> other use case? Please correct if am I wrong.
>>
>> In the second case,I'm using  the separate UI field for getting value for
>> interval and cron , If the cron value is available then polling is working
>> with cron time period , if the cron is not available then the polling is
>> working with the interval.
>> Is there a different way to implement this feature?
>>
>> --
>> Thanks & Regards,
>> Kirishanthy
>> Associate Software Engineer
>> Mobile : +94 778333939
>> kirishan...@wso2.com
>>
>
>
>
> --
> Jagath Ariyarathne
> Technical Lead
> WSO2 Inc.  http://wso2.com/
> Email: jaga...@wso2.com
> Mob  : +94 77 386 7048
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

*Kalyani Yogeswaranathan*

*Associate software engineer*
*WSO2 Inc.*

*Mobile: 0776390284*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [ESB] Adding features for VFS inbound(include option copy and leave as it is) and ESB polling inbound(support with cron).

[Eranga Perera]

Hi,

Another usefull behaviour I think that we should provide is the ability set
some property for vfs inbound, so that when the file is moved/copied the
original name will be appended by some sequence number or a time stamp.
This will be usefull in case if the third party application is generating
the same file name each time it is deposited to the in folder and it will
help to track all files being processed without overwriting the previous
files.

Eranga.

Eranga Perera
Senior Lead Solutions Engineer
WSO2, Inc.
Mobile :  +94 72 778 4250
eran...@wso2.com
On Dec 12, 2015 4:52 PM, "Kalyani Yogeswaranathan"  wrote:

> Hi Kirishanthy,
>
> These resources may help you to get some knowledge about VFS Transport[1]
> and File inbound[2].
>
>1. https://docs.wso2.com/display/ESB490/VFS+Transport
>2. https://docs.wso2.com/display/ESB490/File+Inbound+Protocol
>3.
>
> https://github.com/wso2/carbon-mediation/tree/master/components/inbound-endpoints
>
> Thank you.
>
> On Fri, Dec 11, 2015 at 11:49 AM, Jagath Sisirakumara Ariyarathne <
> jaga...@wso2.com> wrote:
>
>> Hi,
>>
>> To get the input for polling interval/cron configuration, how about using
>> a toggle button like in Scheduled Tasks.
>>
>> [image: Inline image 1]
>>
>> In this case, we can set interval as default selection. Based on the
>> selection, you can use required implementation.
>>
>> Thanks.
>>
>> On Fri, Dec 11, 2015 at 10:56 AM, Kirishanthy Tharmalingam <
>> kirishan...@wso2.com> wrote:
>>
>>> Hi all ,
>>>
>>> Now I'm working on following improvement in the VFS inbound and ESB
>>> polling inbound.
>>>
>>>1. For VFS inbound we only have the option to delete or move file
>>>after processed or after error. Need to give the options copy and  leave 
>>> as
>>>it is.
>>>2. Current ESB polling inbound only support interval. But we need to
>>>have the ability to schedule it using cron expressions.
>>>
>>> In first case leave as it is the good option because we can used the
>>> same file again and again.
>>> In the copy option we copy the same file again and again, so If the file
>>> is already exist in the destination directory delete the file and copy the
>>> file again.
>>> use case of copy option is we can update the content of the file(because
>>> it is exist in the source directory), then the next polling we can copy the
>>> updated file to the destination directory.(because delete the existing file
>>> in the destination directory and copy the updated file).  Is there any
>>> other use case? Please correct if am I wrong.
>>>
>>> In the second case,I'm using  the separate UI field for getting value
>>> for interval and cron , If the cron value is available then polling is
>>> working with cron time period , if the cron is not available then the
>>> polling is working with the interval.
>>> Is there a different way to implement this feature?
>>>
>>> --
>>> Thanks & Regards,
>>> Kirishanthy
>>> Associate Software Engineer
>>> Mobile : +94 778333939
>>> kirishan...@wso2.com
>>>
>>
>>
>>
>> --
>> Jagath Ariyarathne
>> Technical Lead
>> WSO2 Inc.  http://wso2.com/
>> Email: jaga...@wso2.com
>> Mob  : +94 77 386 7048
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
>
> *Kalyani Yogeswaranathan*
>
> *Associate software engineer*
> *WSO2 Inc.*
>
> *Mobile: 0776390284*
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN]Skipping the instance creation with same state

[Firzhan Naqash]

Hi Philippe,

I see your point, but I think those cases can (and should, IMO), be handled
by process-specific logic. Since Activiti is a project which has a very
active development team, I´d think many times before adding new
functionality that is WSO2-specific, even if it is not in the core engine -
I´m assuming that the proposed change would be made at the activiti-rest
module.


Yeah those cases can be handled by process specific logic or from the
client side. If we are going to handle from the client side, we have to
store all the unique business keys in in-memory/database. But lately this
use cases have become a common one across many enterprise workflow
integration and we decided to add the optional "
skipInstanceCreationIfExist" Boolean flag. Even without using this flag
instance creation will work ( In that case flag is false).


Maybe you should post your proposed change in Activiti´s forum and see what
what kind of reation you get from the community.

+1. I will post it in to the community forum.
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [BPMN]Skipping the instance creation with same state

[Firzhan Naqash]

Hi Kasun,

We are only providing the REST API. This implementation uses the set of
underneath Java APIs provided by the Activiti core engine.
If we are to provide a single Java API then we have to patch the core
engine which is not feasible to do.

Regards,
Firzhan


-- 
*Firzhan Naqash*
Senior Software Engineer - Integration Platform Team
WSO2 Inc. http://wso2.com

email: firz...@wso2.com
mobile: (+94) 77 9785674 <%28%2B94%29%2071%205247551>*|
blog: http://firzhanblogger.blogspot.com/
  *
*twitter: https://twitter.com/firzhan007  |
linked-in: **https://www.linkedin.com/in/firzhan
*

On Sat, Dec 12, 2015 at 6:31 PM, Firzhan Naqash  wrote:

>
> Hi Philippe,
>
> I see your point, but I think those cases can (and should, IMO), be
> handled by process-specific logic. Since Activiti is a project which has a
> very active development team, I´d think many times before adding new
> functionality that is WSO2-specific, even if it is not in the core engine -
> I´m assuming that the proposed change would be made at the activiti-rest
> module.
>
>
> Yeah those cases can be handled by process specific logic or from the
> client side. If we are going to handle from the client side, we have to
> store all the unique business keys in in-memory/database. But lately this
> use cases have become a common one across many enterprise workflow
> integration and we decided to add the optional "
> skipInstanceCreationIfExist" Boolean flag. Even without using this flag
> instance creation will work ( In that case flag is false).
>
>
> Maybe you should post your proposed change in Activiti´s forum and see
> what what kind of reation you get from the community.
>
> +1. I will post it in to the community forum.
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] API Manager REST API with tier grouping feature

[Malintha Amarasinghe]

Hi Frank,

/tiers/{tier-level} is a collection. Using "api", "application" or
"resource" for {tier-level} parameter, we can retrieve the collections of
API, application or resource level tiers. We decided to use
/tiers/{tier-level} because in APIM itself they are maintained separately.
I.e. we have 3 separate files in registry to store API, Application and
Resource level tiers. We use POST tiers/{tier-level} to add tiers for each
collection.

Thank you,
Malintha

On Sat, Dec 12, 2015 at 3:59 PM, Frank Leymann  wrote:

> Hi Malintha,
>
> sorry for the late response.  A post is used on a collection to add a new
> resource to this collection. While /tiers is for sure a collection, the
> question is whether /tiers/{tier-level} is a collection too.  Even if it
> is, it sounds a bit strange to me to add a tier to a collection that
> corresponds to a tier-level.
>
> Instead, I assume that the data model of a tier contains more than just a
> tier-level attribute, right?  If tier-level is one of many properties of a
> tier, I suggest that we POST to /tier...
>
>
> Best regards,
> Frank
>
> 2015-12-01 13:10 GMT+01:00 Malintha Amarasinghe :
>
>> Hi Nuwan,
>>
>> Thanks for the clarification.
>>
>> Hi Frank,
>>
>> Yes, would that need to be changed for POST /tiers/{tier-level}? Or shall
>> we keep the previous one (/tiers ) only for POST and identify the tier
>> level from the request body?
>>
>> Thanks.
>>
>>
>> On Tue, Dec 1, 2015 at 5:32 PM, Frank Leymann  wrote:
>>
>>> Just to double-check:  but we still have a POST /tiers to add a new tier
>>> to the collection, right?
>>>
>>>
>>> Best regards,
>>> Frank
>>>
>>> 2015-12-01 11:50 GMT+01:00 Nuwan Dias :
>>>
 I think the group param should be mandatory. Therefore there will not
 be a GET /tiers, but instead a GET /tiers/{level} only.

 Thanks,
 NuwanD.

 On Tue, Dec 1, 2015 at 3:17 PM, Malintha Amarasinghe <
 malint...@wso2.com> wrote:

> Hi Nuwan, Sanjeewa and Joe,
>
> Thanks a lot for all the suggestions.
>
> I have a small doubt for using the group as part of the path.
>
> Lets say we use GET /tiers/api/{tier-id} to get a single API tier by
> its id (actually Name). Then, are we exposing the resource /tiers alone
> too?  If we do, are we returning the tier groups for GET /tiers? In this
> case, returning tiers will not be appropriate IMO as the immediate
> sub-resource is not a tier, but a tier type. Or can we just make the group
> parameter mandatory?
>
> Thank you.
> Malintha
>
> On Tue, Dec 1, 2015 at 11:54 AM, Nuwan Dias  wrote:
>
>>
>>
>> On Tue, Dec 1, 2015 at 11:21 AM, Joseph Fonseka 
>> wrote:
>>
>>> IMO if we have multiple tier files a path param would be more
>>> suitable. If we have only one tier file and the group(level) is an
>>> attribute then we could have use a query param.
>>>
>>> Any specific reason to have a tier file for each level ? Rather than
>>> having an attribute to group tiers. Or for each tier specifying 
>>> application,
>>> API and resource level throttling separately.
>>>
>>
>> Having everything on a single file makes the tier definitions very
>> noisy. Having it separately makes it very clean and easy to manage.
>>
>> For example, the API tiers now have attributes related to billing
>> information. These won't make sense for Application level and Resource
>> level tiers. So having them in separate files makes sense IMO. In 
>> addition
>> to that having them separately allows us to perform access control for
>> those resources as well.
>>
>>>
>>> Thanks
>>> Jo
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Dec 1, 2015 at 10:06 AM, Sanjeewa Malalgoda <
>>> sanje...@wso2.com> wrote:
>>>
 What we agreed last week is let users to fetch tiers based on type,
 It can be either path param like mentioned above or query param
 tiers?tier-level=application.

 Existing users will get same set of tiers for application, API and
 resource.
 But new deployments and people who willing to have different levels
 can change them as per requirements.
 Having same names in application, API and resource level with
 different unit time and count may be bit confusing IMO.
 Still nothing will break as we return requested tier list.

 Thanks,
 sanjeewa.



 On Tue, Dec 1, 2015 at 8:41 AM, Nuwan Dias  wrote:

> @Sanjeewa, users migrating from older versions of API Manager will
> have their tiers duplicated across all levels. And its not wrong for 
> users
> to have the same tier across all levels as well. Therefore having 
> duplicate
> tier names in different levels is valid scenario.
>
> @Jo, yes there's a tier.xm

Re: [Architecture] [Dev] [BPS][BPMN] New REST API for BPMN statistics

[Malintha Amarasinghe]

Hi Natasha,

Giving you a small suggestion to port the documentation to Swagger [1] as
there are many advantages.

1. It is a well structured way of documenting APIs and it is used by many
organizations.

2. Users of your API can use the swagger doc to generate clients. There are
lots of tools that can do it for them including swagger-code-gen tool [2].
They supports many languages including HTML/javascript, Java.

3. Swagger doc can be used to generate server code
skeleton. swagger-code-gen [2] includes that capability also. We used a
customized version of it which is swagger2cxf-maven-plugin [3] to generate
CXF server code when we were implementing the new REST API for API Manager.

4. Swagger doc can be used to generate HTML documentation too. Please note
we are still in the process of doing it. Have a look at below links they
are completely auto generated from Swagger docs, (Please ignore some
characters like \n and * they should be corrected from the code generator.
:) And we are yet to do some beatifications etc )

http://apidocs.wso2.com/rest/apim/store/v1/docs
http://apidocs.wso2.com/rest/apim/publisher/v1/docs

Please have a look at [4] and [5], what we have written for the REST API
which might help you. You can use [6] as a tool for documenting. You might
also have seen before an example of swagger-ui [7] which users can directly
use the Swagger doc to invoke the API.

Thanks,
Malintha

[1] http://swagger.io/specification/
[2] https://github.com/swagger-api/swagger-codegen
[3] https://github.com/hevayo/swagger2cxf-maven-plugin
[4]
https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.store/src/main/resources/store-api.yaml
[5]
https://github.com/wso2/carbon-apimgt/blob/release-1.10.x/components/apimgt/org.wso2.carbon.apimgt.rest.api.publisher/src/main/resources/publisher-api.yaml
[6] http://editor.swagger.io/
[7] http://petstore.swagger.io

--
Malintha Amarasinghe
Software Engineer
*WSO2, Inc. - lean | enterprise | middleware*
http://wso2.com/

Mobile : +94 712383306

On Fri, Dec 11, 2015 at 6:05 PM, Natasha Wijesekara 
wrote:

> I created a documentation jira and attached the api doc.
>
> Thanks
> Natasha
>
> On Fri, Dec 11, 2015 at 4:23 PM, Nandika Jayawardana 
> wrote:
>
>> Lets attach the doc to a documentation jira so that api is added to the
>> documentation.
>>
>> Regards
>> Nandika
>>
>> On Thu, Dec 10, 2015 at 7:03 PM, Natasha Wijesekara 
>> wrote:
>>
>>> Hi,
>>>
>>> @Vinod, I used the format given in the Activiti rest api documentation
>>> to include the response codes.
>>>
>>> @Nuwan, I have updated the user guide with the response codes and the
>>> sample success responses.
>>>
>>>
>>> Thanks,
>>> Natasha
>>>
>>> On Thu, Dec 10, 2015 at 8:39 AM, Vinod Kavinda  wrote:
>>>
 Hi Natasha,
 You can use the format used in Activiti rest api documentations [1] for
 this also. It includes response codes and sample success responses.

 @Dinithi, we are doing basic authentication using the security handler
 [2] AFAIK.

 [1] - http://www.activiti.org/userguide/#_get_a_deployment
 [2] -
 https://github.com/wso2/carbon-business-process/blob/master/components/bpmn/bpmn-rest/src/main/java/org/wso2/carbon/bpmn/rest/security/AuthenticationHandler.java

 Regards,
 Vinod Kavinda

 On Thu, Dec 10, 2015 at 7:30 AM, Dinithi De Silva 
 wrote:

> Hi Natasha,
>
> How are you going to ensure the security of the APIs? Have you thought
> of using any security models?
>
> You can use  permission/role based model in order to achieve this.
> Just make sure which APIs need the administrative privileges.
>
> Thanks.
>
>
> On Wed, Dec 9, 2015 at 9:30 PM, Nuwan Pallewela 
> wrote:
>
>> Hi Natasha,
>>
>> Great work.
>> What happens if an invalid request or request with an illegal
>> argument sent to the API ?
>> It is better to have those response messages or response status code
>> also in the documentation.
>>
>> Thanks,
>> Nuwan
>>
>> On Wed, Dec 9, 2015 at 5:08 PM, Natasha Wijesekara 
>> wrote:
>>
>>> Hi,
>>>
>>> I  documented a user guide which contains details about the new rest
>>> API implemented to generate the statistics for bpmn.
>>> Appreciate any suggestions and comments.
>>>
>>> Thanks,
>>> Natasha
>>>
>>> On Tue, Dec 8, 2015 at 4:44 PM, Vinod Kavinda 
>>> wrote:
>>>
 [Adding Architecture group]

 On Tue, Dec 8, 2015 at 2:45 PM, Natasha Wijesekara <
 nata...@wso2.com> wrote:

> Hi ,
>
> Currently the statistics generated for the bpmn-explorer is
> generated using jaggery. When the work load is high, the  
> bpmn-explorer
> takes a longer time to generate these statistics which causes 
> performance
>