Supporting data mapper isn't straightforward, Also we don't install data
mapper features yet. Supporting all the mediators during the initial
version isn't going to very easy. Hence we need to identify important set
of mediators and build a library that can handle the rest of the mediators.

On Tue, Oct 22, 2019 at 9:40 PM Malintha Amarasinghe <[email protected]>
wrote:

>
> Hi,
>
> We need to make sure the mediators we provide works in single-threaded
> (blocking mode) only. Otherwise the request flow will split. @Others please
> correct me if I am wrong.
>
> On Tue, Oct 22, 2019 at 7:39 PM Dulith Senanayake <[email protected]> wrote:
>
>> Hi all,
>>
>> As @Harsha Kumara <[email protected]> and @Malintha Amarasinghe
>> <[email protected]> mentioned, I identified the following mediator list
>> that we would be supporting at UI level for the request, response, fault
>> message mediations.
>>
>>    - Call
>>
>> We should only encourage blocking mode. Call mediator's asynchronous
> (nonblocking) mode cannot be used in our mediation policies.
>
>>
>>    - Send
>>
>> I think we cannot encourage using Send mediator which is always
> non-blocking? Please correct me if I am wrong.
>
>>
>>    - Log
>>    - Property
>>    - Filter
>>
>> Above 3 should be okay,
>
>
>>
>>    - Sequence
>>
>> Sequences can be used but the problem is we are not properly exporting it
> when exporting an API. When someone does an import/export, the dependent
> sequences will be missing.
>
>>
>>    - CallTemplate
>>
>> I guess it has the same problem as sequences.
>
>>
>>    - Drop
>>
>> Should be okay to provide I guess.
>
>>
>>    - LoopBack
>>
>> Moves the request to the outSequence path. We need to carefully decide
> whether to support or not.
>
>>
>>    - PropertyGroup
>>
>>  Should be okay
>
>>
>>    - Respond
>>    - ConditionalRouter
>>
>>  Above two breaks the default request flow. We need to carefully decide
> whether to support or not.
>
>>
>>    - DataMapper
>>    - PayloadFactory
>>    - Validate
>>    - Switch
>>    - ForEach
>>
>> Above 5 should be okay as this is executed in a single thread (blocking
> mode)
>
>
>>
>>    - Iterate
>>
>> I don't think we can provide Iterate because it is splitting the default
> message flow.
>
> How about mediators like header, script, enrich, urlrewrite, cache? We can
> check possible ones from [1]
>
> Also, with regards to property mediator, it is very useful to provide a
> list of common properties [2], scopes in the UI so that users can discover
> them and use it easily.
>
> [1] https://docs.wso2.com/display/EI640/ESB+Mediators
> [2] https://docs.wso2.com/display/EI640/Properties+Reference
>
> Thanks!
>
>
>> I highly appreciate the comments on the above list of mediators that
>> should be added or removed.
>>
>> Thanks!
>>
>> On Sun, Oct 20, 2019 at 1:02 PM Dulith Senanayake <[email protected]>
>> wrote:
>>
>>> okay...
>>>
>>> Thanks!
>>>
>>> On Sun, Oct 20, 2019 at 12:17 PM Malintha Amarasinghe <
>>> [email protected]> wrote:
>>>
>>>>
>>>> On Sat, Oct 19, 2019 at 12:16 PM Dulith Senanayake <[email protected]>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Can we use *breadcrumbs* navigation scheme to represent multiple
>>>>> execution flows in a simple way for the commonly used mediators like
>>>>> "filter"?
>>>>>
>>>> That should be also fine. We may think of other approaches as well and
>>>> choose a better one.
>>>> As Harsha mentioned, let's decide a list of mediators we would be
>>>> supporting at UI level and it will also help to understand other use cases
>>>> as well.
>>>>
>>>>
>>>>>
>>>>> Thanks!
>>>>>
>>>>> On Sat, Oct 19, 2019 at 4:43 AM Malintha Amarasinghe <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> Hi Dulith,
>>>>>>
>>>>>> The suggested approach and gif representation are great.The above
>>>>>> flow is good and simple IMO for a sequence of mediators with properties.
>>>>>>
>>>>>> Have we thought about mediators like "filter"? In that case, there
>>>>>> will be multiple execution flows and each flow can have a sequence of
>>>>>> mediators.
>>>>>> I believe we shouldn't be showing an extensive mediator tree if it is
>>>>>> time-consuming. But, we'll need a way to represent that in a simple way 
>>>>>> as
>>>>>> the mediators like "filter" is commonly used.
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On Fri, Oct 18, 2019 at 5:53 PM Dulith Senanayake <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> I'm going to implement an UI which supports for single mediation
>>>>>>> policy designing and uploading to the backend which already has support 
>>>>>>> for
>>>>>>> executing single policy for each In, Out, and Fault flow of API
>>>>>>> requests.Following gifs shows how I'm going to implement the UI design 
>>>>>>> for
>>>>>>> uploading custom mediation policies & designing custom mediation 
>>>>>>> policies.
>>>>>>>
>>>>>>> *Uploading custom mediation policies*
>>>>>>>
>>>>>>> Mediation_Flow_uploading.gif (2,512K)
>>>>>>> <https://mail.google.com/mail/u/0?ui=2&ik=e7a860e74d&attid=0.1&permmsgid=msg-a:r-2545341195134784047&view=att&disp=safe&realattid=f_k1vy99dy0>
>>>>>>> --
>>>>>>>
>>>>>>>    - Selecting a common mediation policy procedure same as in the
>>>>>>>    APIM 3.0.0 product.
>>>>>>>    - In the uploading procedure user can upload an existing
>>>>>>>    mediation flow by clicking on upload mediation flow button.user has 
>>>>>>> to
>>>>>>>    select mediation flow from his folders and upload the selected flow.
>>>>>>>    - User can view the source of the uploaded flow by clicking on
>>>>>>>    the source tab.
>>>>>>>    - User can add mediators to the uploaded flow by clicking on the
>>>>>>>    mediators in the right side.
>>>>>>>    - User can delete added mediators,uploaded mediators by right
>>>>>>>    clicking on the mediator that should delete.
>>>>>>>    - User can upload the designed flow to the
>>>>>>>    Request,Response,Fault message mediation by clicking on the select 
>>>>>>> button.
>>>>>>>    - Name of the mediation flow display in the message mediation
>>>>>>>    tab same as in the APIM 3.0.0 product.
>>>>>>>
>>>>>>> *Designing custom mediation policies*
>>>>>>>
>>>>>>> Mediation_Flow_designing.gif
>>>>>>> (986K)
>>>>>>>
>>>>>>> <https://mail.google.com/mail/u/0?ui=2&ik=e7a860e74d&attid=0.2&permmsgid=msg-a:r-2545341195134784047&view=att&disp=safe&realattid=f_k1vyages1>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    - In the designing procedure user must give the name for the
>>>>>>>    designing mediation flow according to the previous naming 
>>>>>>> syntax(cannot
>>>>>>>    have spaces between names & instead of space must use underscore).
>>>>>>>    - User can click on the mediators in the right side to add to
>>>>>>>    the mediation flow.
>>>>>>>    - Properties of each added mediator,displays in the bottom tab.
>>>>>>>    - User can delete any added mediator by right clicking on the
>>>>>>>    mediator.
>>>>>>>    - User can view the source of the added flow by clicking on the
>>>>>>>    source tab.
>>>>>>>    - User cannot upload the designed flow to the message mediation
>>>>>>>    tab if the name has not given for the designed flow(name is a 
>>>>>>> mandatory
>>>>>>>    field).
>>>>>>>    - If the name has given in the name field user can upload the
>>>>>>>    flow to the Request,Response,Fault message mediation by clicking on 
>>>>>>> the
>>>>>>>    select button.
>>>>>>>
>>>>>>> *Technologies that are use in the implementation*
>>>>>>>
>>>>>>>    - React, Webpack, Babel, ES6, JSS, CSS, HTML5
>>>>>>>    - Java,Apache Synapse
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> *Dulith Senanayake* | Intern | WSO2 Inc <http://wso2.com>.
>>>>>>>
>>>>>>> (m) +94770044922 | (e) [email protected]
>>>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Malintha Amarasinghe
>>>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>>>> http://wso2.com/
>>>>>>
>>>>>> Mobile : +94 712383306
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> *Dulith Senanayake* | Intern | WSO2 Inc <http://wso2.com>.
>>>>>
>>>>> (m) +94770044922 | (e) [email protected]
>>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Malintha Amarasinghe
>>>> *WSO2, Inc. - lean | enterprise | middleware*
>>>> http://wso2.com/
>>>>
>>>> Mobile : +94 712383306
>>>>
>>>
>>>
>>> --
>>> *Dulith Senanayake* | Intern | WSO2 Inc <http://wso2.com>.
>>>
>>> (m) +94770044922 | (e) [email protected]
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>
>>>
>>
>> --
>> *Dulith Senanayake* | Intern | WSO2 Inc <http://wso2.com>.
>>
>> (m) +94770044922 | (e) [email protected]
>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>
>>
>
> --
> Malintha Amarasinghe
> *WSO2, Inc. - lean | enterprise | middleware*
> http://wso2.com/
>
> Mobile : +94 712383306
>


-- 

*Harsha Kumara*

Technical Lead, WSO2 Inc.
Mobile: +94775505618
Email: [email protected]
Blog: harshcreationz.blogspot.com

GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to