[Architecture] [Dev] [Announce] WSO2 Enterprise Integrator 6.5.0-M5 Released!

[Arunan Sugunakumar]

The WSO2 Enterprise Integration team is pleased to announce the 5th
milestone of WSO2 Enterprise Integrator 6.5.0.
Download

You can download,

WSO2 Enterprise Integrator 6.5.0 M5 from here

.

WSO2 Micro Integrator 1.0.0 M3 from here

.
What's new in WSO2 Enterprise Integrator 6.5.0-M5

A list of tasks/bug fixes and improvements shipped with this release can be
found below:
Tasks/bug fixes and improvements

Documentation

Online documentation is available at
https://docs.wso2.com/display/EI6xx/WSO2+Enterprise+Integrator+Documentation
Contribute to WSO2 Enterprise IntegratorMailing Lists

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

Developer List: d...@wso2.org
Architecture List: architecture@wso2.org
User Forum: StackOverflow
Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Enterprise Integrator through our public WSO2 Enterprise
Integrator GIT Issues 

~ The WSO2 Enterprise Integration Team ~

-- 
*Sugunakumar Arunan*
Software Engineer | WSO2

Email : aru...@wso2.com
Mobile : +94766016272
Web : http://wso2.com

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

Re: [Architecture] [APIM] Introduce API Product Concept

[Sachini De Silva]

Hi,

For now, we have no intention to force migrate existing APIs to API
products so that there will be only API products in API store. Publishers
can expose their APIs to store directly as they did earlier. Additionally,
with API product feature they can bundle APIs/subsets of resources from
several APIs as a single API product. The store will have a separate view
for API Products.
So basically, API Manager will have both APIs and API Products in store.

Thanks,
Sachini

On Thu, Apr 11, 2019 at 4:30 PM Cyril Rognon  wrote:

> Hi all,
>
> +1 for your feedback Franck : APIProduct should not be only a group of API
> but the public face of the API. Meaning an API has to be a product if
> consumed.
>
> We could think of an automated way to promote an existing API as a
> Product. Hence the store would only show API Products whereas the publisher
> would allow to work with APIs and their Product counterpart (either a
> partial view or a group or ...).
>
> Thanks
> Cyril
>
> Le jeu. 11 avr. 2019 à 11:33, Frank Leymann  a écrit :
>
>> +1 ,   this is a useful feature (although we may invent another name for
>> a group of APIs, because a single API today is subject to monetization,
>> i.e. a "product").
>>
>> Generalizing Chathura's question:  do non-functional properties defined
>> at the collection level (throttlling, security, pricing,...) override the
>> corresponding properties at the "member-API" level?  Can such properties
>> defined both, at the level of the whole collection as well as at the level
>> of individual members?
>>
>> Best regards,
>> Frank
>>
>>
>>
>>
>> Am Di., 9. Apr. 2019 um 10:50 Uhr schrieb Chathura Ekanayake <
>> chath...@wso2.com>:
>>
>>> Hi Sachini,
>>>
>>> Grouping APIs as mentioned is an useful feature. Few comments inline..
>>>
>>> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva 
>>> wrote:
>>>
 Hi all,

 We are planning to introduce API product concept to API Manager.

 An API product is basically a bundle of APIs/ API resources that is
 made available to users to subscribe and consume. API product creator can
 attach a throttling policy and other metadata to the API product. The
 collection of APIs/resources in the product are such that they address a
 specific business use case.

 For example, I have 3 APIs as below. And I need to bundle API A and B
 together, attach a higher throttling limit and make it available for paid
 customers. And bundle API B, C together with a lower throttling limit and
 make it available for free use.

>>>
>>> How does API product level throttling work with API/resource level
>>> throttling? Does it override API/resource level throttling? Or does the
>>> most restrictive policy apply?
>>>
>>>

 [image: image.png]

 Below is how we are planning to implement this feature on APIM.

 1. When a user creates an API product a new scope(without any role
 assigned) will be created and attached to all the api resources he/she is
 allowing for that API product.
 2. Then a user can subscribe to the api product and in order to get a
 token for the API product, he/she has to pass the scope details along with
 the token request.
 3. So that the request can be identified as coming through the API
 product and handled accordingly.

 The reason for using this scope based approach is to avoid creating a
 new gateway resource for the APIs in the product. In above, the requests
 will be directed to the existing APIs deployed in the gateway and the
 request will be distinguished as coming from an API product by using the
 scope attached to the access token.

 Following are several concerns we identified and appreciate your
 thoughts and suggestions on them.

 * At the moment an API resource can’t be assigned multiple scopes. - we
 are currently looking into this.

>>>
>>> So when getting a token does the user has to specify the API product
>>> scope and the resource scope (if any)?
>>>
>>>
 * We are planning to introduce a new API product throttling level. At
 the moment we are further looking into throttling and analytics for API
 products.

 * With regard to UI aspects, we will be adding a new section in API
 publisher UI to create and modify API products. And in store, we will be
 adding a new section to view and subscribe to API products.

 Thanks,
 Sachini
 --

 *Sachini De Silva*
 Software Engineer - WSO2

 Email : sachi...@wso2.com
 Mobile : +94714765495

 ___
>>> 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] [APIM] Introduce API Product Concept

[Cyril Rognon]

Hi all,

+1 for your feedback Franck : APIProduct should not be only a group of API
but the public face of the API. Meaning an API has to be a product if
consumed.

We could think of an automated way to promote an existing API as a Product.
Hence the store would only show API Products whereas the publisher would
allow to work with APIs and their Product counterpart (either a partial
view or a group or ...).

Thanks
Cyril

Le jeu. 11 avr. 2019 à 11:33, Frank Leymann  a écrit :

> +1 ,   this is a useful feature (although we may invent another name for a
> group of APIs, because a single API today is subject to monetization, i.e.
> a "product").
>
> Generalizing Chathura's question:  do non-functional properties defined at
> the collection level (throttlling, security, pricing,...) override the
> corresponding properties at the "member-API" level?  Can such properties
> defined both, at the level of the whole collection as well as at the level
> of individual members?
>
> Best regards,
> Frank
>
>
>
>
> Am Di., 9. Apr. 2019 um 10:50 Uhr schrieb Chathura Ekanayake <
> chath...@wso2.com>:
>
>> Hi Sachini,
>>
>> Grouping APIs as mentioned is an useful feature. Few comments inline..
>>
>> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva 
>> wrote:
>>
>>> Hi all,
>>>
>>> We are planning to introduce API product concept to API Manager.
>>>
>>> An API product is basically a bundle of APIs/ API resources that is made
>>> available to users to subscribe and consume. API product creator can attach
>>> a throttling policy and other metadata to the API product. The collection
>>> of APIs/resources in the product are such that they address a specific
>>> business use case.
>>>
>>> For example, I have 3 APIs as below. And I need to bundle API A and B
>>> together, attach a higher throttling limit and make it available for paid
>>> customers. And bundle API B, C together with a lower throttling limit and
>>> make it available for free use.
>>>
>>
>> How does API product level throttling work with API/resource level
>> throttling? Does it override API/resource level throttling? Or does the
>> most restrictive policy apply?
>>
>>
>>>
>>> [image: image.png]
>>>
>>> Below is how we are planning to implement this feature on APIM.
>>>
>>> 1. When a user creates an API product a new scope(without any role
>>> assigned) will be created and attached to all the api resources he/she is
>>> allowing for that API product.
>>> 2. Then a user can subscribe to the api product and in order to get a
>>> token for the API product, he/she has to pass the scope details along with
>>> the token request.
>>> 3. So that the request can be identified as coming through the API
>>> product and handled accordingly.
>>>
>>> The reason for using this scope based approach is to avoid creating a
>>> new gateway resource for the APIs in the product. In above, the requests
>>> will be directed to the existing APIs deployed in the gateway and the
>>> request will be distinguished as coming from an API product by using the
>>> scope attached to the access token.
>>>
>>> Following are several concerns we identified and appreciate your
>>> thoughts and suggestions on them.
>>>
>>> * At the moment an API resource can’t be assigned multiple scopes. - we
>>> are currently looking into this.
>>>
>>
>> So when getting a token does the user has to specify the API product
>> scope and the resource scope (if any)?
>>
>>
>>> * We are planning to introduce a new API product throttling level. At
>>> the moment we are further looking into throttling and analytics for API
>>> products.
>>>
>>> * With regard to UI aspects, we will be adding a new section in API
>>> publisher UI to create and modify API products. And in store, we will be
>>> adding a new section to view and subscribe to API products.
>>>
>>> Thanks,
>>> Sachini
>>> --
>>>
>>> *Sachini De Silva*
>>> Software Engineer - WSO2
>>>
>>> Email : sachi...@wso2.com
>>> Mobile : +94714765495
>>>
>>> ___
>> 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
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [APIM] Introduce API Product Concept

[Frank Leymann]

+1 ,   this is a useful feature (although we may invent another name for a
group of APIs, because a single API today is subject to monetization, i.e.
a "product").

Generalizing Chathura's question:  do non-functional properties defined at
the collection level (throttlling, security, pricing,...) override the
corresponding properties at the "member-API" level?  Can such properties
defined both, at the level of the whole collection as well as at the level
of individual members?

Best regards,
Frank




Am Di., 9. Apr. 2019 um 10:50 Uhr schrieb Chathura Ekanayake <
chath...@wso2.com>:

> Hi Sachini,
>
> Grouping APIs as mentioned is an useful feature. Few comments inline..
>
> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva  wrote:
>
>> Hi all,
>>
>> We are planning to introduce API product concept to API Manager.
>>
>> An API product is basically a bundle of APIs/ API resources that is made
>> available to users to subscribe and consume. API product creator can attach
>> a throttling policy and other metadata to the API product. The collection
>> of APIs/resources in the product are such that they address a specific
>> business use case.
>>
>> For example, I have 3 APIs as below. And I need to bundle API A and B
>> together, attach a higher throttling limit and make it available for paid
>> customers. And bundle API B, C together with a lower throttling limit and
>> make it available for free use.
>>
>
> How does API product level throttling work with API/resource level
> throttling? Does it override API/resource level throttling? Or does the
> most restrictive policy apply?
>
>
>>
>> [image: image.png]
>>
>> Below is how we are planning to implement this feature on APIM.
>>
>> 1. When a user creates an API product a new scope(without any role
>> assigned) will be created and attached to all the api resources he/she is
>> allowing for that API product.
>> 2. Then a user can subscribe to the api product and in order to get a
>> token for the API product, he/she has to pass the scope details along with
>> the token request.
>> 3. So that the request can be identified as coming through the API
>> product and handled accordingly.
>>
>> The reason for using this scope based approach is to avoid creating a new
>> gateway resource for the APIs in the product. In above, the requests will
>> be directed to the existing APIs deployed in the gateway and the request
>> will be distinguished as coming from an API product by using the scope
>> attached to the access token.
>>
>> Following are several concerns we identified and appreciate your thoughts
>> and suggestions on them.
>>
>> * At the moment an API resource can’t be assigned multiple scopes. - we
>> are currently looking into this.
>>
>
> So when getting a token does the user has to specify the API product scope
> and the resource scope (if any)?
>
>
>> * We are planning to introduce a new API product throttling level. At the
>> moment we are further looking into throttling and analytics for API
>> products.
>>
>> * With regard to UI aspects, we will be adding a new section in API
>> publisher UI to create and modify API products. And in store, we will be
>> adding a new section to view and subscribe to API products.
>>
>> Thanks,
>> Sachini
>> --
>>
>> *Sachini De Silva*
>> Software Engineer - WSO2
>>
>> Email : sachi...@wso2.com
>> Mobile : +94714765495
>>
>> ___
> 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] [APIM] Introduce API Product Concept

[Chamila Adhikarinayake]

Hi All,
Please find the rests APIs for Publisher[1] and store[2] for API Product.
New rest APIs are introduced except for store's /subscriptions/* resources
(New element for apiproductId is added to the existing payload )

[1]
https://app.swaggerhub.com/apis-docs/chamilaadhi/wso-2_api_manager_publisher_api/0.14.0
[2]
https://app.swaggerhub.com/apis-docs/chamilaadhi/wso-2_api_manager_store/0.14.0#/

Thanks,
Chamila.


On Wed, Apr 10, 2019 at 9:35 AM Nuwan Dias  wrote:

> In addition to bundling APIs, an important feature with API products is
> the ability to create products with only parts of APIs. For example you
> have an API with 20 resources that performs various actions. You may want
> to create 2 API products with that API. One product with only the read-only
> operations of that API (5 resources) and sell it at a certain price. And
> the other product with all operations available at a higher price than the
> former.
>
> On Wed, Apr 10, 2019 at 9:22 AM Sachini De Silva 
> wrote:
>
>> Hi Chathura,
>>
>> Please find my answers below.
>>
>> "*How does API product level throttling work with API/resource level
>> throttling? Does it override API/resource level throttling? Or does the
>> most restrictive policy apply?*"
>>
>> Resource level policies will be inherited from underlying APIs. API level
>> subscription policy will get overridden by product level subscription
>> policies.
>>
>> "*So when getting a token does the user has to specify the API product
>> scope and the resource scope (if any)?*"
>>
>> Yes, normal oauth scope rules will not get affected.
>>
>>
>> Thanks,
>>
>> Sachini
>>
>> On Tue, Apr 9, 2019 at 2:20 PM Chathura Ekanayake 
>> wrote:
>>
>>> Hi Sachini,
>>>
>>> Grouping APIs as mentioned is an useful feature. Few comments inline..
>>>
>>> On Tue, Apr 2, 2019 at 2:25 PM Sachini De Silva 
>>> wrote:
>>>
 Hi all,

 We are planning to introduce API product concept to API Manager.

 An API product is basically a bundle of APIs/ API resources that is
 made available to users to subscribe and consume. API product creator can
 attach a throttling policy and other metadata to the API product. The
 collection of APIs/resources in the product are such that they address a
 specific business use case.

 For example, I have 3 APIs as below. And I need to bundle API A and B
 together, attach a higher throttling limit and make it available for paid
 customers. And bundle API B, C together with a lower throttling limit and
 make it available for free use.

>>>
>>> How does API product level throttling work with API/resource level
>>> throttling? Does it override API/resource level throttling? Or does the
>>> most restrictive policy apply?
>>>
>>>

 [image: image.png]

 Below is how we are planning to implement this feature on APIM.

 1. When a user creates an API product a new scope(without any role
 assigned) will be created and attached to all the api resources he/she is
 allowing for that API product.
 2. Then a user can subscribe to the api product and in order to get a
 token for the API product, he/she has to pass the scope details along with
 the token request.
 3. So that the request can be identified as coming through the API
 product and handled accordingly.

 The reason for using this scope based approach is to avoid creating a
 new gateway resource for the APIs in the product. In above, the requests
 will be directed to the existing APIs deployed in the gateway and the
 request will be distinguished as coming from an API product by using the
 scope attached to the access token.

 Following are several concerns we identified and appreciate your
 thoughts and suggestions on them.

 * At the moment an API resource can’t be assigned multiple scopes. - we
 are currently looking into this.

>>>
>>> So when getting a token does the user has to specify the API product
>>> scope and the resource scope (if any)?
>>>
>>>
 * We are planning to introduce a new API product throttling level. At
 the moment we are further looking into throttling and analytics for API
 products.

 * With regard to UI aspects, we will be adding a new section in API
 publisher UI to create and modify API products. And in store, we will be
 adding a new section to view and subscribe to API products.

 Thanks,
 Sachini
 --

 *Sachini De Silva*
 Software Engineer - WSO2

 Email : sachi...@wso2.com
 Mobile : +94714765495


>>
>> --
>>
>> *Sachini De Silva*
>> Software Engineer - WSO2
>>
>> Email : sachi...@wso2.com
>> Mobile : +94714765495
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> *Nuwan Dias* | Director | WSO2 Inc.
> (m) +94 777 775 729 | (e)