Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Pubudu Gunatilaka 
Hi Harsha/Anuruddha,

What do we store in *gateway_config.yaml*? Are those Kubernetes resources
such as services, deployments,etc?

Thank you!

On Mon, May 28, 2018 at 9:32 AM Sanjeewa Malalgoda 
wrote:

>
>
> On Mon, May 28, 2018 at 6:10 PM, Lakmal Warusawithana 
> wrote:
>
>>
>> On Mon, May 28, 2018 at 5:57 PM Rajith Roshan  wrote:
>>
>>> I think we have to decide whether we are going to allow users to edit
>>> generated bal files. If so then they can write some custom logic and
>>> generate the balx files. If we are not allowing them to edit bal files then
>>> micro gw will be only pass through with some filters.
>>>
>>
>> I thought we already in agreement of shipping  only proxy capability in
>> this release.
>>
> Yes, lets keep this simple for this release and improve it in future.
>
>>
>>
>>> On Mon, May 28, 2018 at 5:30 PM Isuru Haththotuwa 
>>> wrote:
>>>


 On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda 
 wrote:

>
>
> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara 
> wrote:
>
>> Hi All,
>>
>> We are working on releasing a ballerina based micro gateway with APIM
>> 2.5.0. We are providing are Cli Tool which allow users to generate
>> ballerina executables and runtime archives based on provided 
>> configurations.
>>
>> High Level Architecture
>> [image: image.png]
>>
>> *Micro gateway distribution structure*
>>
>> micro-gw
>> ├── bin
>> │   ├── micro-gw.bat
>> │   └── micro-gw.sh
>> ├── lib
>> │   └── ballerina-0.970.0
>> ├── temp
>> │   └── path.txt
>> └── templates
>> ├── api.mustache
>> ├── config.mustache
>> └── gateway_config.mustache
>> └── policy_template.mustache
>>
>>
>> *Core Cli Commands*
>>
>>- *micro-gw setup/init (with inputs username, label name and
>>password(*optional
>> *)) *
>>   - This command will create basic project structure. Initially
>>   consumer key and secret will be generated by taking user inputs and
>>   retrieve the api definitions of given label type in the argument. 
>> If user
>>   provides new label, there will be new directory structure for that 
>> label
>>   will be created under projects directory.
>>   - *projects* directory contains directories for each label and
>>   ballerina source file will be created for each API under 
>> particular label
>>   - *config.yaml* contains configurations related to publisher,
>>   key manager connections, consumer key and secret which are common 
>> across
>>   all labels
>>   - *gateway_config.yaml* contains configurations specific to
>>   labels such as docker/kubernetes
>>
>> Shouldn't we provide  publisher URL along with this command? If
> publisher is hosted server and micro gateway runs within local machine 
> then
> we may need to point to that publisher(something similar to current micro
> gateway scenario).
>
 The init/setup command will only create the project structure.
 Communicating with the Publisher, pulling the API definition and building
 the corresponding .balx file & the runnable distribution happens with the
 build command.

>
>>
>> *   Generated Project Structure*
>>
>> micro-gw-resources
>>
>> ├── conf
>>
>> │   └── config.yaml
>>
>> └── projects (folder name is same as label name)
>>
>> ├── accounts
>>
>> │   ├── src
>>
>> │   │   ├── companyAccounts_v1.0.0.bal
>>
>> │   │   └── salesforce_v1.0.0.bal
>>
>> │   └── target
>>
>> │   ├── accounts.balx
>>
>> │   └── accounts.zip
>>
>> ├── finance
>>
>> │   ├── src
>>
>> │   │   ├── invoices_v2.0.0.bal
>>
>> │   │   └── payments_v2.1.0.bal
>>
>> │   └── target
>>
>> │   ├── finance.balx
>>
>> │   └── finance.zip
>>
>> ├── gateway-config
>>
>> │   └── gateway-config.yaml
>>
>> └── sales
>>
>> ├── src
>>
>> │   ├── customers_v3.0.0.bal
>>
>> │   └── leads_v4.0.0.bal
>>
>> └── target
>>
>> ├── sales.balx
>>
>> └── sales.zip
>>
>> I think we can directly point this directory to composer and
> implement some custom mediation logic there. In case synapse API have its
> own mediation sequence which we cannot directly translate to ballerina.
>
 This would be a limitation. Running any custom mediation sequences in
 the micro gw will not be supported.

>

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Sanjeewa Malalgoda 
On Mon, May 28, 2018 at 6:10 PM, Lakmal Warusawithana 
wrote:

>
> On Mon, May 28, 2018 at 5:57 PM Rajith Roshan  wrote:
>
>> I think we have to decide whether we are going to allow users to edit
>> generated bal files. If so then they can write some custom logic and
>> generate the balx files. If we are not allowing them to edit bal files then
>> micro gw will be only pass through with some filters.
>>
>
> I thought we already in agreement of shipping  only proxy capability in
> this release.
>
Yes, lets keep this simple for this release and improve it in future.

>
>
>> On Mon, May 28, 2018 at 5:30 PM Isuru Haththotuwa 
>> wrote:
>>
>>>
>>>
>>> On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda 
>>> wrote:
>>>


 On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara 
 wrote:

> Hi All,
>
> We are working on releasing a ballerina based micro gateway with APIM
> 2.5.0. We are providing are Cli Tool which allow users to generate
> ballerina executables and runtime archives based on provided 
> configurations.
>
> High Level Architecture
> [image: image.png]
>
> *Micro gateway distribution structure*
>
> micro-gw
> ├── bin
> │   ├── micro-gw.bat
> │   └── micro-gw.sh
> ├── lib
> │   └── ballerina-0.970.0
> ├── temp
> │   └── path.txt
> └── templates
> ├── api.mustache
> ├── config.mustache
> └── gateway_config.mustache
> └── policy_template.mustache
>
>
> *Core Cli Commands*
>
>- *micro-gw setup/init (with inputs username, label name and
>password(*optional
> *)) *
>   - This command will create basic project structure. Initially
>   consumer key and secret will be generated by taking user inputs and
>   retrieve the api definitions of given label type in the argument. 
> If user
>   provides new label, there will be new directory structure for that 
> label
>   will be created under projects directory.
>   - *projects* directory contains directories for each label and
>   ballerina source file will be created for each API under particular 
> label
>   - *config.yaml* contains configurations related to publisher,
>   key manager connections, consumer key and secret which are common 
> across
>   all labels
>   - *gateway_config.yaml* contains configurations specific to
>   labels such as docker/kubernetes
>
> Shouldn't we provide  publisher URL along with this command? If
 publisher is hosted server and micro gateway runs within local machine then
 we may need to point to that publisher(something similar to current micro
 gateway scenario).

>>> The init/setup command will only create the project structure.
>>> Communicating with the Publisher, pulling the API definition and building
>>> the corresponding .balx file & the runnable distribution happens with the
>>> build command.
>>>

>
> *   Generated Project Structure*
>
> micro-gw-resources
>
> ├── conf
>
> │   └── config.yaml
>
> └── projects (folder name is same as label name)
>
> ├── accounts
>
> │   ├── src
>
> │   │   ├── companyAccounts_v1.0.0.bal
>
> │   │   └── salesforce_v1.0.0.bal
>
> │   └── target
>
> │   ├── accounts.balx
>
> │   └── accounts.zip
>
> ├── finance
>
> │   ├── src
>
> │   │   ├── invoices_v2.0.0.bal
>
> │   │   └── payments_v2.1.0.bal
>
> │   └── target
>
> │   ├── finance.balx
>
> │   └── finance.zip
>
> ├── gateway-config
>
> │   └── gateway-config.yaml
>
> └── sales
>
> ├── src
>
> │   ├── customers_v3.0.0.bal
>
> │   └── leads_v4.0.0.bal
>
> └── target
>
> ├── sales.balx
>
> └── sales.zip
>
> I think we can directly point this directory to composer and implement
 some custom mediation logic there. In case synapse API have its own
 mediation sequence which we cannot directly translate to ballerina.

>>> This would be a limitation. Running any custom mediation sequences in
>>> the micro gw will not be supported.
>>>

>- *micro-gw build (with inputs label name)*
>   - This command build single balx out of all APIs belongs to
>   given label. If docker/kubernetes configurations specified,
>   then archive will be generated. This archive will embeds bre, 
> generated

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Lakmal Warusawithana 
On Mon, May 28, 2018 at 5:57 PM Rajith Roshan  wrote:

> I think we have to decide whether we are going to allow users to edit
> generated bal files. If so then they can write some custom logic and
> generate the balx files. If we are not allowing them to edit bal files then
> micro gw will be only pass through with some filters.
>

I thought we already in agreement of shipping  only proxy capability in
this release.


> On Mon, May 28, 2018 at 5:30 PM Isuru Haththotuwa  wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>>
>>>
>>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>>>
 Hi All,

 We are working on releasing a ballerina based micro gateway with APIM
 2.5.0. We are providing are Cli Tool which allow users to generate
 ballerina executables and runtime archives based on provided 
 configurations.

 High Level Architecture
 [image: image.png]

 *Micro gateway distribution structure*

 micro-gw
 ├── bin
 │   ├── micro-gw.bat
 │   └── micro-gw.sh
 ├── lib
 │   └── ballerina-0.970.0
 ├── temp
 │   └── path.txt
 └── templates
 ├── api.mustache
 ├── config.mustache
 └── gateway_config.mustache
 └── policy_template.mustache


 *Core Cli Commands*

- *micro-gw setup/init (with inputs username, label name and
password(*optional
 *)) *
   - This command will create basic project structure. Initially
   consumer key and secret will be generated by taking user inputs and
   retrieve the api definitions of given label type in the argument. If 
 user
   provides new label, there will be new directory structure for that 
 label
   will be created under projects directory.
   - *projects* directory contains directories for each label and
   ballerina source file will be created for each API under particular 
 label
   - *config.yaml* contains configurations related to publisher,
   key manager connections, consumer key and secret which are common 
 across
   all labels
   - *gateway_config.yaml* contains configurations specific to
   labels such as docker/kubernetes

 Shouldn't we provide  publisher URL along with this command? If
>>> publisher is hosted server and micro gateway runs within local machine then
>>> we may need to point to that publisher(something similar to current micro
>>> gateway scenario).
>>>
>> The init/setup command will only create the project structure.
>> Communicating with the Publisher, pulling the API definition and building
>> the corresponding .balx file & the runnable distribution happens with the
>> build command.
>>
>>>

 *   Generated Project Structure*

 micro-gw-resources

 ├── conf

 │   └── config.yaml

 └── projects (folder name is same as label name)

 ├── accounts

 │   ├── src

 │   │   ├── companyAccounts_v1.0.0.bal

 │   │   └── salesforce_v1.0.0.bal

 │   └── target

 │   ├── accounts.balx

 │   └── accounts.zip

 ├── finance

 │   ├── src

 │   │   ├── invoices_v2.0.0.bal

 │   │   └── payments_v2.1.0.bal

 │   └── target

 │   ├── finance.balx

 │   └── finance.zip

 ├── gateway-config

 │   └── gateway-config.yaml

 └── sales

 ├── src

 │   ├── customers_v3.0.0.bal

 │   └── leads_v4.0.0.bal

 └── target

 ├── sales.balx

 └── sales.zip

 I think we can directly point this directory to composer and implement
>>> some custom mediation logic there. In case synapse API have its own
>>> mediation sequence which we cannot directly translate to ballerina.
>>>
>> This would be a limitation. Running any custom mediation sequences in the
>> micro gw will not be supported.
>>
>>>
- *micro-gw build (with inputs label name)*
   - This command build single balx out of all APIs belongs to
   given label. If docker/kubernetes configurations specified, then
   archive will be generated. This archive will embeds bre, generated 
 balx
   which someone can take and run without configuring anything.
   - This command also outputs APIs which have updated and commands
   which are available to run in target folder
- *micro-gw run (with label name)*
   - This command will use to run the balx generated for given

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Rajith Roshan 
I think we have to decide whether we are going to allow users to edit
generated bal files. If so then they can write some custom logic and
generate the balx files. If we are not allowing them to edit bal files then
micro gw will be only pass through with some filters.

On Mon, May 28, 2018 at 5:30 PM Isuru Haththotuwa  wrote:

>
>
> On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>>
>>> Hi All,
>>>
>>> We are working on releasing a ballerina based micro gateway with APIM
>>> 2.5.0. We are providing are Cli Tool which allow users to generate
>>> ballerina executables and runtime archives based on provided configurations.
>>>
>>> High Level Architecture
>>> [image: image.png]
>>>
>>> *Micro gateway distribution structure*
>>>
>>> micro-gw
>>> ├── bin
>>> │   ├── micro-gw.bat
>>> │   └── micro-gw.sh
>>> ├── lib
>>> │   └── ballerina-0.970.0
>>> ├── temp
>>> │   └── path.txt
>>> └── templates
>>> ├── api.mustache
>>> ├── config.mustache
>>> └── gateway_config.mustache
>>> └── policy_template.mustache
>>>
>>>
>>> *Core Cli Commands*
>>>
>>>- *micro-gw setup/init (with inputs username, label name and
>>>password(*optional
>>> *)) *
>>>   - This command will create basic project structure. Initially
>>>   consumer key and secret will be generated by taking user inputs and
>>>   retrieve the api definitions of given label type in the argument. If 
>>> user
>>>   provides new label, there will be new directory structure for that 
>>> label
>>>   will be created under projects directory.
>>>   - *projects* directory contains directories for each label and
>>>   ballerina source file will be created for each API under particular 
>>> label
>>>   - *config.yaml* contains configurations related to publisher, key
>>>   manager connections, consumer key and secret which are common across 
>>> all
>>>   labels
>>>   - *gateway_config.yaml* contains configurations specific to
>>>   labels such as docker/kubernetes
>>>
>>> Shouldn't we provide  publisher URL along with this command? If
>> publisher is hosted server and micro gateway runs within local machine then
>> we may need to point to that publisher(something similar to current micro
>> gateway scenario).
>>
> The init/setup command will only create the project structure.
> Communicating with the Publisher, pulling the API definition and building
> the corresponding .balx file & the runnable distribution happens with the
> build command.
>
>>
>>>
>>> *   Generated Project Structure*
>>>
>>> micro-gw-resources
>>>
>>> ├── conf
>>>
>>> │   └── config.yaml
>>>
>>> └── projects (folder name is same as label name)
>>>
>>> ├── accounts
>>>
>>> │   ├── src
>>>
>>> │   │   ├── companyAccounts_v1.0.0.bal
>>>
>>> │   │   └── salesforce_v1.0.0.bal
>>>
>>> │   └── target
>>>
>>> │   ├── accounts.balx
>>>
>>> │   └── accounts.zip
>>>
>>> ├── finance
>>>
>>> │   ├── src
>>>
>>> │   │   ├── invoices_v2.0.0.bal
>>>
>>> │   │   └── payments_v2.1.0.bal
>>>
>>> │   └── target
>>>
>>> │   ├── finance.balx
>>>
>>> │   └── finance.zip
>>>
>>> ├── gateway-config
>>>
>>> │   └── gateway-config.yaml
>>>
>>> └── sales
>>>
>>> ├── src
>>>
>>> │   ├── customers_v3.0.0.bal
>>>
>>> │   └── leads_v4.0.0.bal
>>>
>>> └── target
>>>
>>> ├── sales.balx
>>>
>>> └── sales.zip
>>>
>>> I think we can directly point this directory to composer and implement
>> some custom mediation logic there. In case synapse API have its own
>> mediation sequence which we cannot directly translate to ballerina.
>>
> This would be a limitation. Running any custom mediation sequences in the
> micro gw will not be supported.
>
>>
>>>- *micro-gw build (with inputs label name)*
>>>   - This command build single balx out of all APIs belongs to given
>>>   label. If docker/kubernetes configurations specified, then
>>>   archive will be generated. This archive will embeds bre, generated 
>>> balx
>>>   which someone can take and run without configuring anything.
>>>   - This command also outputs APIs which have updated and commands
>>>   which are available to run in target folder
>>>- *micro-gw run (with label name)*
>>>   - This command will use to run the balx generated for given label.
>>>
>>> Please share your suggestions and improvements.
>>>
>>>
>>> Thanks,
>>> Harsha
>>> --
>>> Harsha Kumara
>>> Associate Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94 712933253
>>
>>

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Isuru Haththotuwa 
On Mon, May 28, 2018 at 5:03 PM, Sanjeewa Malalgoda 
wrote:

>
>
> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>
>> Hi All,
>>
>> We are working on releasing a ballerina based micro gateway with APIM
>> 2.5.0. We are providing are Cli Tool which allow users to generate
>> ballerina executables and runtime archives based on provided configurations.
>>
>> High Level Architecture
>> [image: image.png]
>>
>> *Micro gateway distribution structure*
>>
>> micro-gw
>> ├── bin
>> │   ├── micro-gw.bat
>> │   └── micro-gw.sh
>> ├── lib
>> │   └── ballerina-0.970.0
>> ├── temp
>> │   └── path.txt
>> └── templates
>> ├── api.mustache
>> ├── config.mustache
>> └── gateway_config.mustache
>> └── policy_template.mustache
>>
>>
>> *Core Cli Commands*
>>
>>- *micro-gw setup/init (with inputs username, label name and
>>password(*optional
>> *)) *
>>   - This command will create basic project structure. Initially
>>   consumer key and secret will be generated by taking user inputs and
>>   retrieve the api definitions of given label type in the argument. If 
>> user
>>   provides new label, there will be new directory structure for that 
>> label
>>   will be created under projects directory.
>>   - *projects* directory contains directories for each label and
>>   ballerina source file will be created for each API under particular 
>> label
>>   - *config.yaml* contains configurations related to publisher, key
>>   manager connections, consumer key and secret which are common across 
>> all
>>   labels
>>   - *gateway_config.yaml* contains configurations specific to labels
>>   such as docker/kubernetes
>>
>> Shouldn't we provide  publisher URL along with this command? If publisher
> is hosted server and micro gateway runs within local machine then we may
> need to point to that publisher(something similar to current micro gateway
> scenario).
>
The init/setup command will only create the project structure.
Communicating with the Publisher, pulling the API definition and building
the corresponding .balx file & the runnable distribution happens with the
build command.

>
>>
>> *   Generated Project Structure*
>>
>> micro-gw-resources
>>
>> ├── conf
>>
>> │   └── config.yaml
>>
>> └── projects (folder name is same as label name)
>>
>> ├── accounts
>>
>> │   ├── src
>>
>> │   │   ├── companyAccounts_v1.0.0.bal
>>
>> │   │   └── salesforce_v1.0.0.bal
>>
>> │   └── target
>>
>> │   ├── accounts.balx
>>
>> │   └── accounts.zip
>>
>> ├── finance
>>
>> │   ├── src
>>
>> │   │   ├── invoices_v2.0.0.bal
>>
>> │   │   └── payments_v2.1.0.bal
>>
>> │   └── target
>>
>> │   ├── finance.balx
>>
>> │   └── finance.zip
>>
>> ├── gateway-config
>>
>> │   └── gateway-config.yaml
>>
>> └── sales
>>
>> ├── src
>>
>> │   ├── customers_v3.0.0.bal
>>
>> │   └── leads_v4.0.0.bal
>>
>> └── target
>>
>> ├── sales.balx
>>
>> └── sales.zip
>>
>> I think we can directly point this directory to composer and implement
> some custom mediation logic there. In case synapse API have its own
> mediation sequence which we cannot directly translate to ballerina.
>
This would be a limitation. Running any custom mediation sequences in the
micro gw will not be supported.

>
>>- *micro-gw build (with inputs label name)*
>>   - This command build single balx out of all APIs belongs to given
>>   label. If docker/kubernetes configurations specified, then archive
>>   will be generated. This archive will embeds bre, generated balx which
>>   someone can take and run without configuring anything.
>>   - This command also outputs APIs which have updated and commands
>>   which are available to run in target folder
>>- *micro-gw run (with label name)*
>>   - This command will use to run the balx generated for given label.
>>
>> Please share your suggestions and improvements.
>>
>>
>> Thanks,
>> Harsha
>> --
>> Harsha Kumara
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94 712933253
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>


-- 
Thanks and Regards,

Isuru H.
+94 716 358 048* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Sanjeewa Malalgoda 
On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:

> Hi All,
>
> We are working on releasing a ballerina based micro gateway with APIM
> 2.5.0. We are providing are Cli Tool which allow users to generate
> ballerina executables and runtime archives based on provided configurations.
>
> High Level Architecture
> [image: image.png]
>
> *Micro gateway distribution structure*
>
> micro-gw
> ├── bin
> │   ├── micro-gw.bat
> │   └── micro-gw.sh
> ├── lib
> │   └── ballerina-0.970.0
> ├── temp
> │   └── path.txt
> └── templates
> ├── api.mustache
> ├── config.mustache
> └── gateway_config.mustache
> └── policy_template.mustache
>
>
> *Core Cli Commands*
>
>- *micro-gw setup/init (with inputs username, label name and password(*
>optional
> *)) *
>   - This command will create basic project structure. Initially
>   consumer key and secret will be generated by taking user inputs and
>   retrieve the api definitions of given label type in the argument. If 
> user
>   provides new label, there will be new directory structure for that label
>   will be created under projects directory.
>   - *projects* directory contains directories for each label and
>   ballerina source file will be created for each API under particular 
> label
>   - *config.yaml* contains configurations related to publisher, key
>   manager connections, consumer key and secret which are common across all
>   labels
>   - *gateway_config.yaml* contains configurations specific to labels
>   such as docker/kubernetes
>
> Shouldn't we provide  publisher URL along with this command? If publisher
is hosted server and micro gateway runs within local machine then we may
need to point to that publisher(something similar to current micro gateway
scenario).

>
>
> *   Generated Project Structure*
>
> micro-gw-resources
>
> ├── conf
>
> │   └── config.yaml
>
> └── projects (folder name is same as label name)
>
> ├── accounts
>
> │   ├── src
>
> │   │   ├── companyAccounts_v1.0.0.bal
>
> │   │   └── salesforce_v1.0.0.bal
>
> │   └── target
>
> │   ├── accounts.balx
>
> │   └── accounts.zip
>
> ├── finance
>
> │   ├── src
>
> │   │   ├── invoices_v2.0.0.bal
>
> │   │   └── payments_v2.1.0.bal
>
> │   └── target
>
> │   ├── finance.balx
>
> │   └── finance.zip
>
> ├── gateway-config
>
> │   └── gateway-config.yaml
>
> └── sales
>
> ├── src
>
> │   ├── customers_v3.0.0.bal
>
> │   └── leads_v4.0.0.bal
>
> └── target
>
> ├── sales.balx
>
> └── sales.zip
>
> I think we can directly point this directory to composer and implement
some custom mediation logic there. In case synapse API have its own
mediation sequence which we cannot directly translate to ballerina.

>
>- *micro-gw build (with inputs label name)*
>   - This command build single balx out of all APIs belongs to given
>   label. If docker/kubernetes configurations specified, then archive
>   will be generated. This archive will embeds bre, generated balx which
>   someone can take and run without configuring anything.
>   - This command also outputs APIs which have updated and commands
>   which are available to run in target folder
>- *micro-gw run (with label name)*
>   - This command will use to run the balx generated for given label.
>
> Please share your suggestions and improvements.
>
>
> Thanks,
> Harsha
> --
> Harsha Kumara
> Associate Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Blog:harshcreationz.blogspot.com
>



-- 
*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94 712933253

blog
:http://sanjeewamalalgoda.blogspot.com/

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

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Nuwan Dias 
Instead of naming the templates under a directory called 'templates', we
should probably generalize that and say 'resources'.

On Mon, May 28, 2018 at 3:36 PM, Rukshan Premathunga 
wrote:

> Hi Harsha,
>
> Where do we store generated policies bals? Since it is not related to
> labels we can put it to separate directory under the projects dir.
>
> Thanks and Regards
>
> On Mon, May 28, 2018 at 3:33 PM, Harsha Kumara  wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 3:31 PM Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>>>
 *Core Cli Commands*

- *micro-gw setup/init (with inputs username, label name and
password(*optional
 *)) *

 I think the project path shoul be an input for this.
>>>
>> Yes
>>
>>>
>>>
 micro-gw-resources

 ├── conf

 │   └── config.yaml

 └── projects (folder name is same as label name)

 ├── accounts

 │   ├── src

 │   │   ├── companyAccounts_v1.0.0.bal

 │   │   └── salesforce_v1.0.0.bal

 │   └── target

 │   ├── accounts.balx

 │   └── accounts.zip

 ├── finance

 │   ├── src

 │   │   ├── invoices_v2.0.0.bal

 │   │   └── payments_v2.1.0.bal

 │   └── target

 │   ├── finance.balx

 │   └── finance.zip

 ├── gateway-config

 │   └── gateway-config.yaml


>>> Shouldn't this come under every label? f
>>>
>> Yes structure should be as follow.
>> micro-gw-resources
>> ├── conf
>> │   └── config.yaml
>> └── projects
>> ├── accounts
>> │   ├── gateway-config
>> │   │   └── gateway-config.yaml
>> │   ├── src
>> │   │   ├── companyAccounts_v1.0.0.bal
>> │   │   └── salesforce_v1.0.0.bal
>> │   └── target
>> │   ├── accounts.balx
>> │   └── accounts.zip
>> ├── finance
>> │   ├── gateway-config
>> │   │   └── gateway-config.yaml
>> │   ├── src
>> │   │   ├── invoices_v2.0.0.bal
>> │   │   └── payments_v2.1.0.bal
>> │   └── target
>> │   ├── finance.balx
>> │   └── finance.zip
>> └── sales
>> ├── gateway-config
>> │   └── gateway-config.yaml
>> ├── src
>> │   ├── customers_v3.0.0.bal
>> │   └── leads_v4.0.0.bal
>> └── target
>> ├── sales.balx
>> └── sales.zip
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
 └── sales

 ├── src

 │   ├── customers_v3.0.0.bal

 │   └── leads_v4.0.0.bal

 └── target

 ├── sales.balx

 └── sales.zip


- *micro-gw build (with inputs label name)*
   - This command build single balx out of all APIs belongs to
   given label. If docker/kubernetes configurations specified, then
   archive will be generated. This archive will embeds bre, generated 
 balx
   which someone can take and run without configuring anything.
   - This command also outputs APIs which have updated and commands
   which are available to run in target folder
- *micro-gw run (with label name)*
   - This command will use to run the balx generated for given
   label.

 Please share your suggestions and improvements.


 Thanks,
 Harsha
 --
 Harsha Kumara
 Associate Technical Lead, WSO2 Inc.
 Mobile: +94775505618
 Blog:harshcreationz.blogspot.com

>>>
>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com *
>>>
>>> *Phone: +94715478185*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> *
>>> *Twitter: https://twitter.com/bhathiyax *
>>> *Blog: http://movingaheadblog.blogspot.com
>>> *
>>>
>>
>>
>> --
>> Harsha Kumara
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
> +94711822074
>



-- 
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Harsha Kumara 
On Mon, May 28, 2018 at 3:36 PM Rukshan Premathunga 
wrote:

> Hi Harsha,
>
> Where do we store generated policies bals? Since it is not related to
> labels we can put it to separate directory under the projects dir.
>
Yes we can do that.

>
> Thanks and Regards
>
> On Mon, May 28, 2018 at 3:33 PM, Harsha Kumara  wrote:
>
>>
>>
>> On Mon, May 28, 2018 at 3:31 PM Bhathiya Jayasekara 
>> wrote:
>>
>>> Hi,
>>>
>>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>>>
 *Core Cli Commands*

- *micro-gw setup/init (with inputs username, label name and
password(*optional
 *)) *

 I think the project path shoul be an input for this.
>>>
>> Yes
>>
>>>
>>>
 micro-gw-resources

 ├── conf

 │   └── config.yaml

 └── projects (folder name is same as label name)

 ├── accounts

 │   ├── src

 │   │   ├── companyAccounts_v1.0.0.bal

 │   │   └── salesforce_v1.0.0.bal

 │   └── target

 │   ├── accounts.balx

 │   └── accounts.zip

 ├── finance

 │   ├── src

 │   │   ├── invoices_v2.0.0.bal

 │   │   └── payments_v2.1.0.bal

 │   └── target

 │   ├── finance.balx

 │   └── finance.zip

 ├── gateway-config

 │   └── gateway-config.yaml


>>> Shouldn't this come under every label? f
>>>
>> Yes structure should be as follow.
>> micro-gw-resources
>> ├── conf
>> │   └── config.yaml
>> └── projects
>> ├── accounts
>> │   ├── gateway-config
>> │   │   └── gateway-config.yaml
>> │   ├── src
>> │   │   ├── companyAccounts_v1.0.0.bal
>> │   │   └── salesforce_v1.0.0.bal
>> │   └── target
>> │   ├── accounts.balx
>> │   └── accounts.zip
>> ├── finance
>> │   ├── gateway-config
>> │   │   └── gateway-config.yaml
>> │   ├── src
>> │   │   ├── invoices_v2.0.0.bal
>> │   │   └── payments_v2.1.0.bal
>> │   └── target
>> │   ├── finance.balx
>> │   └── finance.zip
>> └── sales
>> ├── gateway-config
>> │   └── gateway-config.yaml
>> ├── src
>> │   ├── customers_v3.0.0.bal
>> │   └── leads_v4.0.0.bal
>> └── target
>> ├── sales.balx
>> └── sales.zip
>>
>>
>>> Thanks,
>>> Bhathiya
>>>
>>>
 └── sales

 ├── src

 │   ├── customers_v3.0.0.bal

 │   └── leads_v4.0.0.bal

 └── target

 ├── sales.balx

 └── sales.zip


- *micro-gw build (with inputs label name)*
   - This command build single balx out of all APIs belongs to
   given label. If docker/kubernetes configurations specified, then
   archive will be generated. This archive will embeds bre, generated 
 balx
   which someone can take and run without configuring anything.
   - This command also outputs APIs which have updated and commands
   which are available to run in target folder
- *micro-gw run (with label name)*
   - This command will use to run the balx generated for given
   label.

 Please share your suggestions and improvements.


 Thanks,
 Harsha
 --
 Harsha Kumara
 Associate Technical Lead, WSO2 Inc.
 Mobile: +94775505618
 Blog:harshcreationz.blogspot.com

>>>
>>>
>>>
>>> --
>>> *Bhathiya Jayasekara*
>>> *Associate Technical Lead,*
>>> *WSO2 inc., http://wso2.com *
>>>
>>> *Phone: +94715478185*
>>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>>> *
>>> *Twitter: https://twitter.com/bhathiyax *
>>> *Blog: http://movingaheadblog.blogspot.com
>>> *
>>>
>>
>>
>> --
>> Harsha Kumara
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> Rukshan Chathuranga.
> Software Engineer.
> WSO2, Inc.
> +94711822074
>


-- 
Harsha Kumara
Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Rukshan Premathunga 
Hi Harsha,

Where do we store generated policies bals? Since it is not related to
labels we can put it to separate directory under the projects dir.

Thanks and Regards

On Mon, May 28, 2018 at 3:33 PM, Harsha Kumara  wrote:

>
>
> On Mon, May 28, 2018 at 3:31 PM Bhathiya Jayasekara 
> wrote:
>
>> Hi,
>>
>> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>>
>>> *Core Cli Commands*
>>>
>>>- *micro-gw setup/init (with inputs username, label name and
>>>password(*optional
>>> *)) *
>>>
>>> I think the project path shoul be an input for this.
>>
> Yes
>
>>
>>
>>> micro-gw-resources
>>>
>>> ├── conf
>>>
>>> │   └── config.yaml
>>>
>>> └── projects (folder name is same as label name)
>>>
>>> ├── accounts
>>>
>>> │   ├── src
>>>
>>> │   │   ├── companyAccounts_v1.0.0.bal
>>>
>>> │   │   └── salesforce_v1.0.0.bal
>>>
>>> │   └── target
>>>
>>> │   ├── accounts.balx
>>>
>>> │   └── accounts.zip
>>>
>>> ├── finance
>>>
>>> │   ├── src
>>>
>>> │   │   ├── invoices_v2.0.0.bal
>>>
>>> │   │   └── payments_v2.1.0.bal
>>>
>>> │   └── target
>>>
>>> │   ├── finance.balx
>>>
>>> │   └── finance.zip
>>>
>>> ├── gateway-config
>>>
>>> │   └── gateway-config.yaml
>>>
>>>
>> Shouldn't this come under every label? f
>>
> Yes structure should be as follow.
> micro-gw-resources
> ├── conf
> │   └── config.yaml
> └── projects
> ├── accounts
> │   ├── gateway-config
> │   │   └── gateway-config.yaml
> │   ├── src
> │   │   ├── companyAccounts_v1.0.0.bal
> │   │   └── salesforce_v1.0.0.bal
> │   └── target
> │   ├── accounts.balx
> │   └── accounts.zip
> ├── finance
> │   ├── gateway-config
> │   │   └── gateway-config.yaml
> │   ├── src
> │   │   ├── invoices_v2.0.0.bal
> │   │   └── payments_v2.1.0.bal
> │   └── target
> │   ├── finance.balx
> │   └── finance.zip
> └── sales
> ├── gateway-config
> │   └── gateway-config.yaml
> ├── src
> │   ├── customers_v3.0.0.bal
> │   └── leads_v4.0.0.bal
> └── target
> ├── sales.balx
> └── sales.zip
>
>
>> Thanks,
>> Bhathiya
>>
>>
>>> └── sales
>>>
>>> ├── src
>>>
>>> │   ├── customers_v3.0.0.bal
>>>
>>> │   └── leads_v4.0.0.bal
>>>
>>> └── target
>>>
>>> ├── sales.balx
>>>
>>> └── sales.zip
>>>
>>>
>>>- *micro-gw build (with inputs label name)*
>>>   - This command build single balx out of all APIs belongs to given
>>>   label. If docker/kubernetes configurations specified, then
>>>   archive will be generated. This archive will embeds bre, generated 
>>> balx
>>>   which someone can take and run without configuring anything.
>>>   - This command also outputs APIs which have updated and commands
>>>   which are available to run in target folder
>>>- *micro-gw run (with label name)*
>>>   - This command will use to run the balx generated for given label.
>>>
>>> Please share your suggestions and improvements.
>>>
>>>
>>> Thanks,
>>> Harsha
>>> --
>>> Harsha Kumara
>>> Associate Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Blog:harshcreationz.blogspot.com
>>>
>>
>>
>>
>> --
>> *Bhathiya Jayasekara*
>> *Associate Technical Lead,*
>> *WSO2 inc., http://wso2.com *
>>
>> *Phone: +94715478185*
>> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
>> *
>> *Twitter: https://twitter.com/bhathiyax *
>> *Blog: http://movingaheadblog.blogspot.com
>> *
>>
>
>
> --
> Harsha Kumara
> Associate Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Blog:harshcreationz.blogspot.com
>



-- 
Rukshan Chathuranga.
Software Engineer.
WSO2, Inc.
+94711822074
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Harsha Kumara 
On Mon, May 28, 2018 at 3:31 PM Bhathiya Jayasekara 
wrote:

> Hi,
>
> On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:
>
>> *Core Cli Commands*
>>
>>- *micro-gw setup/init (with inputs username, label name and
>>password(*optional
>> *)) *
>>
>> I think the project path shoul be an input for this.
>
Yes

>
>
>> micro-gw-resources
>>
>> ├── conf
>>
>> │   └── config.yaml
>>
>> └── projects (folder name is same as label name)
>>
>> ├── accounts
>>
>> │   ├── src
>>
>> │   │   ├── companyAccounts_v1.0.0.bal
>>
>> │   │   └── salesforce_v1.0.0.bal
>>
>> │   └── target
>>
>> │   ├── accounts.balx
>>
>> │   └── accounts.zip
>>
>> ├── finance
>>
>> │   ├── src
>>
>> │   │   ├── invoices_v2.0.0.bal
>>
>> │   │   └── payments_v2.1.0.bal
>>
>> │   └── target
>>
>> │   ├── finance.balx
>>
>> │   └── finance.zip
>>
>> ├── gateway-config
>>
>> │   └── gateway-config.yaml
>>
>>
> Shouldn't this come under every label? f
>
Yes structure should be as follow.
micro-gw-resources
├── conf
│   └── config.yaml
└── projects
├── accounts
│   ├── gateway-config
│   │   └── gateway-config.yaml
│   ├── src
│   │   ├── companyAccounts_v1.0.0.bal
│   │   └── salesforce_v1.0.0.bal
│   └── target
│   ├── accounts.balx
│   └── accounts.zip
├── finance
│   ├── gateway-config
│   │   └── gateway-config.yaml
│   ├── src
│   │   ├── invoices_v2.0.0.bal
│   │   └── payments_v2.1.0.bal
│   └── target
│   ├── finance.balx
│   └── finance.zip
└── sales
├── gateway-config
│   └── gateway-config.yaml
├── src
│   ├── customers_v3.0.0.bal
│   └── leads_v4.0.0.bal
└── target
├── sales.balx
└── sales.zip


> Thanks,
> Bhathiya
>
>
>> └── sales
>>
>> ├── src
>>
>> │   ├── customers_v3.0.0.bal
>>
>> │   └── leads_v4.0.0.bal
>>
>> └── target
>>
>> ├── sales.balx
>>
>> └── sales.zip
>>
>>
>>- *micro-gw build (with inputs label name)*
>>   - This command build single balx out of all APIs belongs to given
>>   label. If docker/kubernetes configurations specified, then archive
>>   will be generated. This archive will embeds bre, generated balx which
>>   someone can take and run without configuring anything.
>>   - This command also outputs APIs which have updated and commands
>>   which are available to run in target folder
>>- *micro-gw run (with label name)*
>>   - This command will use to run the balx generated for given label.
>>
>> Please share your suggestions and improvements.
>>
>>
>> Thanks,
>> Harsha
>> --
>> Harsha Kumara
>> Associate Technical Lead, WSO2 Inc.
>> Mobile: +94775505618
>> Blog:harshcreationz.blogspot.com
>>
>
>
>
> --
> *Bhathiya Jayasekara*
> *Associate Technical Lead,*
> *WSO2 inc., http://wso2.com *
>
> *Phone: +94715478185*
> *LinkedIn: http://www.linkedin.com/in/bhathiyaj
> *
> *Twitter: https://twitter.com/bhathiyax *
> *Blog: http://movingaheadblog.blogspot.com
> *
>


-- 
Harsha Kumara
Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Bhathiya Jayasekara 
Hi,

On Mon, May 28, 2018 at 3:23 PM, Harsha Kumara  wrote:

> *Core Cli Commands*
>
>- *micro-gw setup/init (with inputs username, label name and password(*
>optional
> *)) *
>
> I think the project path shoul be an input for this.


> micro-gw-resources
>
> ├── conf
>
> │   └── config.yaml
>
> └── projects (folder name is same as label name)
>
> ├── accounts
>
> │   ├── src
>
> │   │   ├── companyAccounts_v1.0.0.bal
>
> │   │   └── salesforce_v1.0.0.bal
>
> │   └── target
>
> │   ├── accounts.balx
>
> │   └── accounts.zip
>
> ├── finance
>
> │   ├── src
>
> │   │   ├── invoices_v2.0.0.bal
>
> │   │   └── payments_v2.1.0.bal
>
> │   └── target
>
> │   ├── finance.balx
>
> │   └── finance.zip
>
> ├── gateway-config
>
> │   └── gateway-config.yaml
>
>
Shouldn't this come under every label?

Thanks,
Bhathiya


> └── sales
>
> ├── src
>
> │   ├── customers_v3.0.0.bal
>
> │   └── leads_v4.0.0.bal
>
> └── target
>
> ├── sales.balx
>
> └── sales.zip
>
>
>- *micro-gw build (with inputs label name)*
>   - This command build single balx out of all APIs belongs to given
>   label. If docker/kubernetes configurations specified, then archive
>   will be generated. This archive will embeds bre, generated balx which
>   someone can take and run without configuring anything.
>   - This command also outputs APIs which have updated and commands
>   which are available to run in target folder
>- *micro-gw run (with label name)*
>   - This command will use to run the balx generated for given label.
>
> Please share your suggestions and improvements.
>
>
> Thanks,
> Harsha
> --
> Harsha Kumara
> Associate Technical Lead, WSO2 Inc.
> Mobile: +94775505618
> Blog:harshcreationz.blogspot.com
>



-- 
*Bhathiya Jayasekara*
*Associate Technical Lead,*
*WSO2 inc., http://wso2.com *

*Phone: +94715478185*
*LinkedIn: http://www.linkedin.com/in/bhathiyaj
*
*Twitter: https://twitter.com/bhathiyax *
*Blog: http://movingaheadblog.blogspot.com
*
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] APIM Micro Gateway Cli Functionality and Structure

2018-05-28 Thread Harsha Kumara 
Hi All,

We are working on releasing a ballerina based micro gateway with APIM
2.5.0. We are providing are Cli Tool which allow users to generate
ballerina executables and runtime archives based on provided configurations.

High Level Architecture
[image: image.png]

*Micro gateway distribution structure*

micro-gw
├── bin
│   ├── micro-gw.bat
│   └── micro-gw.sh
├── lib
│   └── ballerina-0.970.0
├── temp
│   └── path.txt
└── templates
├── api.mustache
├── config.mustache
└── gateway_config.mustache
└── policy_template.mustache


*Core Cli Commands*

   - *micro-gw setup/init (with inputs username, label name and password(*
   optional
*)) *
  - This command will create basic project structure. Initially
  consumer key and secret will be generated by taking user inputs and
  retrieve the api definitions of given label type in the argument. If user
  provides new label, there will be new directory structure for that label
  will be created under projects directory.
  - *projects* directory contains directories for each label and
  ballerina source file will be created for each API under particular label
  - *config.yaml* contains configurations related to publisher, key
  manager connections, consumer key and secret which are common across all
  labels
  - *gateway_config.yaml* contains configurations specific to labels
  such as docker/kubernetes



*   Generated Project Structure*

micro-gw-resources

├── conf

│   └── config.yaml

└── projects (folder name is same as label name)

├── accounts

│   ├── src

│   │   ├── companyAccounts_v1.0.0.bal

│   │   └── salesforce_v1.0.0.bal

│   └── target

│   ├── accounts.balx

│   └── accounts.zip

├── finance

│   ├── src

│   │   ├── invoices_v2.0.0.bal

│   │   └── payments_v2.1.0.bal

│   └── target

│   ├── finance.balx

│   └── finance.zip

├── gateway-config

│   └── gateway-config.yaml

└── sales

├── src

│   ├── customers_v3.0.0.bal

│   └── leads_v4.0.0.bal

└── target

├── sales.balx

└── sales.zip


   - *micro-gw build (with inputs label name)*
  - This command build single balx out of all APIs belongs to given
  label. If docker/kubernetes configurations specified, then archive
  will be generated. This archive will embeds bre, generated balx which
  someone can take and run without configuring anything.
  - This command also outputs APIs which have updated and commands
  which are available to run in target folder
   - *micro-gw run (with label name)*
  - This command will use to run the balx generated for given label.

Please share your suggestions and improvements.


Thanks,
Harsha
-- 
Harsha Kumara
Associate Technical Lead, WSO2 Inc.
Mobile: +94775505618
Blog:harshcreationz.blogspot.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture