Hi Lahiru, Arunan,
So the syntax would be like:
*<transform [schema="conf:/schema.json"]> <property
name="">value</property>+</transform> *
example:
<transform>
<property name="synapse.commons.json.preserve.namespace">true</property>
</transform>
So I believe these properties simply just override globally configured
properties for a specific mediation flow.
@Lahiru Madushanka <[email protected]> : Regarding JSON schema
generation. Is the same spec is used to generate schema for datamapper?
Thanks,
Milinda
On Sun, Jul 14, 2019 at 9:43 PM Lahiru Madushanka <[email protected]>
wrote:
> Hi Arunan,
>
> Great stuff.
> I have a suggestion to extend the functionality of the new Transform
> mediator.
>
> As I believe, the following is a summary of the current situation
>
> - There are some problems occurring due to the information gap between
> XML and JSON data types.
> - We already have solutions for some of these problems like
> auto-primitive, processing instructions etc...
> - But, all those solutions are applied system-wide.
> - Customers need a way to have a fine tune control over these
> features. ( Ex: need auto-primitive enabled for one proxy and disabled for
> the other )
>
> I am suggesting to integrate all these scattered features into the
> Transform mediator.
> So, the JSON schema will be optional and there will be a set of properties
> to set to true or false.
> Depending on the enabled properties we can generate the JSON and update
> the JSON stream in a2mc.
>
> As I believe, the suggested feature has the following cons.
>
> - It resolves the immediate problem we have on achieving fine-tune
> control over message conversions.
> - A single place to control all convertion related properties.
> - Smooth the migration process to the new JSON schema based solution.
> ( when migrating users can start with configuring properties ( what they
> already have ) and go for JSON schema for edge cases )
>
> Apart from above, when implementing this mediator in EI tooling we should
> have a functionality to generate a JSON schema from a given JSON.
> That way, the user can easily get started and do the necessary fine-tune
> steps to the resulting schema.
>
> Thanks,
> Lahiru
>
> On Sun, Jul 14, 2019 at 12:49 PM Arunan Sugunakumar <[email protected]>
> wrote:
>
>> Hi all,
>>
>> Currently I have implemented native JSON support for Header and Foreach
>> mediator.[1] Now the following JSONPath usages are allowed.
>>
>> <header name="header-symbol" expression="json-eval($.symbol)"/>
>>
>> <foreach id="foreach_1" expression="json-eval($.getQuote.request)">
>> <sequence>
>> <log level="full"/>
>> </sequence>
>> </foreach>
>>
>>
>> As I mentioned in the previous email, I have started working on a
>> Transform mediator[2] to manipulate the JSON payload. The basic syntax
>> would be as follows.
>>
>> <transform schema="conf:/schema.json"/>
>>
>> The idea here is that, the user will give a schema adhering to the
>> standards[3] and transform mediator will manipulate the payload
>> accordingly. The schema can either be a partial or a complete one. Since we
>> have implemented native JSON support for most of the mediators, a user
>> should be able to do most of the mediation without this mediator. But for
>> the users who are using XML specific mediators (like XSLT), this mediator
>> will help to have more control over the XML to JSON transformations. This
>> mediator will make sure that both the payload in the JSON stream and the
>> Envelope are up to date. Also this enables us to perform XML to JSON
>> transformation that is specific to an artifact rather applying global
>> settings. A user can choose to write different schema for different
>> artifacts.
>>
>> Please provide your feedback and suggestions on the above implementation
>> if you have any. Also please note that the "Transform mediator" is still a
>> working title and you can provide your suggestions for a proper name.
>>
>> [1] - https://github.com/wso2/product-ei/issues/4121
>> [2] - https://github.com/wso2/product-ei/issues/4377
>> [3] - https://json-schema.org/
>>
>> Thank you,
>> Arunan
>>
>> On Thu, Jun 13, 2019 at 1:55 PM Arunan Sugunakumar <[email protected]>
>> wrote:
>>
>>> Hi Chathura,
>>>
>>> On Thu, Jun 13, 2019 at 10:10 AM Chathura Ekanayake <[email protected]>
>>> wrote:
>>>
>>>> Hi Arunan,
>>>>
>>>> Enhancing EI JSON support is very useful. Does this change the syntax
>>>> or introduce new syntax? If so, could you give some samples.
>>>>
>>>
>>> Yes, It introduces new syntax. But it will not effect existing users or
>>> the configurations. To use the native JSON support, instead of giving XPath
>>> expressions we need to give JSONPath expressions within "json-eval()". A
>>> sample configuration for Iterate mediator is given below.
>>>
>>> <iterate id="jsonIterator" preservePayload="true"
>>> attachPath="json-eval($.placeHolder)"
>>> expression="json-eval($.students.studentlist)">
>>> <target>
>>> <sequence/>
>>> </target>
>>> </iterate>
>>>
>>> All the JSONPath supported mediators currently have a similar syntax.
>>>
>>>
>>>> Regarding the JSON schema based transformation, how does the transform
>>>> mediator determine mappings. Do we have to specify mappings as a part of
>>>> the config?
>>>>
>>>
>>> Yes, we need to give the schema to transform the payload. Currently the
>>> user have limited control over how the XML converts to JSON. By defining a
>>> schema (either a partial or a complete one), the user can correct the
>>> payload as he wants. This will be highly useful when you are using XML only
>>> mediators (like XSLT) to manipulate a JSON payload. I will elaborate more
>>> and share some samples once we have finalised the implementation details.
>>>
>>> Thanks & Regards,
>>> Arunan
>>>
>>>>
>>>> On Fri, Jun 7, 2019 at 12:27 PM Arunan Sugunakumar <[email protected]>
>>>> wrote:
>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>> I am working on implementing native JSON support for Synapse
>>>>> mediators. As part of the effort, we have to implement JSON support in all
>>>>> the relevant mediators and currently we have implemented native JSON
>>>>> support to Iterate, Aggregate and Enrich mediators. We have to implement
>>>>> it
>>>>> for ForEach, Header, Publish Event, Rule and Call Template mediator. Other
>>>>> mediators either already have JSON support or not relevant to handling
>>>>> JSON
>>>>> payloads (eg XSLT mediator). Please see the attachment for a complete
>>>>> analysis.
>>>>>
>>>>> Initially all the JSON payloads sent to the Synapse got transformed
>>>>> into XML and all the mediators manipulated the payload as XML using XPath.
>>>>> This approach led to some issues such as some of the original information
>>>>> in the JSON payload was lost during the conversion. As a remedy, it was
>>>>> decided to implement native JSON support to the mediators. The original
>>>>> payload exists as a stream in the Message Context and the JSON supported
>>>>> mediators use that stream to do the data manipulation and after the
>>>>> manipulation, the stream and the SOAP envelope are updated. Currently the
>>>>> problem is that, to handle JSON payloads natively, we can only use JSON
>>>>> supported mediators in the mediation. If we use a non JSON supported
>>>>> mediator, the JSON payload in the JSON stream becomes obsolete and we have
>>>>> to use XPath to manipulate the JSON payload in the remaining mediators.
>>>>>
>>>>> As a solution, we can implement JSON support for all the relevant
>>>>> mediators and minimize this problem. This solution is totally backward
>>>>> compatible and existing users can continue to manipulate JSON payload via
>>>>> XPath if they want. To give users more control over the payload, we are
>>>>> also planning to introduce a new Transform mediator which will take a
>>>>> payload and a schema as input, and it will give out a modified payload
>>>>> according to the schema as output.
>>>>>
>>>>>
>>>>> [image: Transform mediator (2).png]
>>>>> Any suggestions or concerns are highly appreciated.
>>>>>
>>>>> Thanks & Regards,
>>>>> Arunan
>>>>>
>>>>> --
>>>>> *Sugunakumar Arunan*
>>>>> Software Engineer | WSO2
>>>>>
>>>>> Email : [email protected]
>>>>> Mobile : +94766016272
>>>>> Web : http://wso2.com
>>>>> <https://wso2.com/signature>
>>>>>
>>>>
>>>
>>> --
>>> *Sugunakumar Arunan*
>>> Software Engineer | WSO2
>>>
>>> Email : [email protected]
>>> Mobile : +94766016272
>>> Web : http://wso2.com
>>> <https://wso2.com/signature>
>>>
>>
>>
>> --
>> *Sugunakumar Arunan*
>> Software Engineer | WSO2
>>
>> Email : [email protected]
>> Mobile : +94766016272
>> Web : http://wso2.com
>> <https://wso2.com/signature>
>>
>
>
> --
> *Lahiru Madushanka* | Software Engineer | WSO2 Inc.
> 071 7276083 | [email protected]
> GET INTEGRATION AGILE
> Integration Agility for Digitally Driven Business
> <http://wso2.com/signature>
>
--
Milinda Perera
Associate Technical Lead
WSO2 Inc. http://wso2.com ,
Mobile: (+94) 714 115 032
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
