Hi Chathura, Thanks for the suggestion. In the implementation, we can support ESB transaction (to make sure it is within the same transaction).
Alternatively, for transactions you can use request_box feature where you don't need to define the transaction mediator. It works across multiple datasources. Thanks On Thu, Jun 13, 2019 at 10:55 AM Chathura Ekanayake <[email protected]> wrote: > As this implementation works with local java method calls, can we make it > work with the transaction mediator without using distributed transactions? > E.g. use multiple dscall mediators withing a JDBC transaction. > > On Tue, Jun 4, 2019 at 5:28 PM Chanika Geeganage <[email protected]> wrote: > >> Hi, >> >> Currently, to invoke a dataservice operation we have to use call mediator >> after creating a payload using payload factory mediator and setting up >> necessary headers (ex: SOAPAction header), even though the dataservice >> features and mediation features are shipped under same EI profile. >> >> Because of that, >> 1. Invoking through HTTP transport adds network latency and that impacts >> on the performance. >> 2. The payload has to be created separately and that creates an overhead >> in the deployment time. >> >> Therefore as a solution, we can directly call the dataservice by using >> dataservice methods internally in a new mediator. The implemented on this >> was carried out as an intern project sometime back and the discussion can >> be found in [1]. But it supports single operations only. Request box or >> batch requests are not supported and therefore, we can extend that to >> support all kinds of operations. >> >> Here is the suggested configuration for the mediator (DSCall Mediator), >> >> <dscall> <dsname>RDBMSSample</dsname> <operations type="single"> < >> operation name="addEmployee"> <param name="id">1</param> <param name= >> "firstname">Peter</param> <param name="lastName">Parker</param> <param >> name="email">[email protected]</param> <param name="salary">12</param> </ >> operation> </operations> <target name="string" type="envelope" /> </ >> dscall> >> >> Here, we can define operations type to differentiate single, request_box >> and batch requests. If it is a request box or batch request, the user can >> define multiple operations. For an example, >> >> <dscall> >> <dsname>RDBMSSample</dsname> <operations type="request_box"> <operation >> name="addEmployee"> <param name="id">1</param> <param name="firstname"> >> Peter</param> <param name="lastName">Parker</param> <param name="email"> >> [email protected]</param> <param name="salary">12</param> </operation> < >> operation name="employeesByNumber"> <param name="employeeNumber">1</param >> > </operation> </operations> <target type="envelope" /> </dscall> >> >> The target is to define whether the response of the dataservice >> invocation is set to the message context or to a property. If it is a >> property the property name can be defined. >> >> Further, it is required to provide integrator studio support as well for >> this new mediator. >> >> You suggestions on this are highly appreciated. >> >> [1] Implementing a DSS-call mediator for invocation of data services. >> >> Thanks >> -- >> >> *Chanika Geeganage* | Associate Technical Lead | WSO2 Inc. >> >> (m) +94-77-3522586 | (e) [email protected] >> >> <https://wso2.com/signature> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > -- *Chanika Geeganage* | Associate Technical Lead | WSO2 Inc. (m) +94-77-3522586 | (e) [email protected] <https://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
