I can't seem to find a way to combine two api json response by using wso developer studio. I'm still reading their documentation and i found that there is a mediator called aggregate mediator but i can't seem cant to find a way to combine the api calls and map it all while using the wso developer studio. So for example Google Contacts and Fullcontact api combines the response
In aggregate mediator, you can not aggregate responses coming from different services. When you are using aggregate mediator you have to use it with clone/iterate mediators. Those mediators will send identical clones/ chunks of message to different endpoints. Those responses will be gathered by aggregate mediator.
In your scenario, you have to use Service Chaining pattern in ESB. Please refer WSO2 documentation [1] and this blog post series [2] will help you to implement your scenario.
You can implement this pattern using developer studio. Just identify what are the components (Ex: Proxy) you need and implement them through Dev Studio.
[1] https://docs.wso2.com/display/ESB490/Service+Chaining+Example
[2] http://dakshithar.blogspot.com/2012/06/routing-and-service-chaining-with-wso2.html
It is difficult to recommend the mediators that you should use, without knowing exact use case. Scatter-Gather pattern with clone and aggregate mediators would be fine if your services are independent(one does not require other's output as input).
If they are dependent, invoke the first one using mediator and you may use a property mediator to remember the output. After the second call, you can combine them using a Payload Factory mediator or, if it is a complex integration, you may use XSLT mediator.
Related
We are working on a solution built on top of WSO2 APIM.
Problem Statement:
We want to add custom capability in existing APIM. Right now if we consume a single api endpoint it gives us meaningful statics some of them are:
API Usage API
API Usage per Application
Top Users per Application
Resource Usage per Application
But what we need is to store some/all incoming request data into database and extract meaningful information over time.
Example:
Suppose we have a api endpoint like below:
HTTP-Verb: POST
URL: http://localhost:9444/subscriptions/1/create_subscription
Params: name:sample_name, type:sample_type, user_id:12345
What we want?
It could be WSO2, OpenAM or any other opensource API manager.
We need to store parameter values e.g. sample_name, sample_type
and user_id in database.
Observations?
Looks like WSO Stream Processor can provide this functionality.
As it has a solution for HTTP Analytics. But we are not certain
to proceed with this option.
Another possible candidate is to Extend API Manager. But docs doesn't have anything to target what we wanted to do.
I am not sure but we can use RequestInterceptor?
Anyone has a experience with this kind of problem please let me know.
There are two problems you have to solve here,
1. Capture the required data from the APIM side
2. Publish to Analytics Server
3. Perform Analytics on received events
As you have observed WSO2 SP can be used for 3.
For 1 & 2, please see blog (https://medium.com/#naduni_pamudika/how-to-publish-custom-attributes-from-wso2-api-manager-to-wso2-analytics-38dd83e8aea2) for extending the publishers to capture and publish additional data.
You can also take a look at OpenIG, it is easy to extend and you can implement your own filter to store request data in database. Another approach is develop your own gateway based on Netflix Zuul or Spring Cloud Gateway
If I have a more complex code within my sequence where I can not do only with using existing mediators, can I create a sequence with a custom java logic ? how do u support it within dev - studio ?
Yes you can write custom mediators for WSO2 ESB.
This is all what you want to know about custom mediators.
This is a sample custom mediator explained.
Hope this helps.
I know that I can use xslt to transform xml, but it costs a lot.
I would like to know whether it is possible using grovvy or not.
Assume I have two xml schema, and transfer them into java file, build to class and deploy to esb.
And I transfer xml via groovy so that I can dynamically change the mapping without deployment java code.
WSO2 ESB supports Mediators implemented in a variety of scripting languages such as JavaScript, Groovy. (https://docs.wso2.org/display/ESB481/Script+Mediator)
To execute a Groovy script using the WSO2 ESB's script mediator follow below tutorial
http://heshans.blogspot.com/2011/05/executing-groovy-scripts-using-wso2-esb.html
This is a Groovy sample I wrote using WSO2 ESB Script mediator. This is for Json payload. However you can do the same for XML. Get payload using mc.getPayloadXML() method and use Groovy XmlSlurper class to parse xml to Groovy objects.
I am new to WSO2 and don't know how to use the declaritive programming widgets to create the REST contract. My use case; I have a backend SOAP 1.2 Web Service that I want to wrap with a REST API in WSO2. I don't know what media to use to define the JSON data contract so it is avalable in the sequence flow. I want to be able to visually map from the JSON payload to the SOAP payload. I really wanted to have two declaritive objects that I drag onto the sequence pallet so I can map from the JSON to the SOAP XML.
Thanks much
You can use a XSLT mediator (Sample 440) or Script mediator (Sample 441) to do the JSON to SOAP mapping. But you will have to type in the XSLT template or the script content manually after adding the mediators through Developer Studio. I don't think you can visually map elements from JSON payload to SOAP.
Go through above samples or this webinar to learn how do the transformations.
I am working on WSO2 ESB 4.0.3 on MAC OS X Lion (10.7.4)
I would like to know what are the best practices for development for WSO2 ESB 4.0.3.
Currently I am using Data Services Feature in it and existing tomcat application, which we are trying to port to WSO2 ESB, does the SQL query in 2-3 seconds where as WSO2 ESB 4.0.3 with Data Services feature taking around 16-17 secodns.
I would be thankful if some body can let me know best practices for WSO2 and in perticular XSLT transformation.
Hoping for answer.
thanks
Hi Prabath
Here is how my environment is
I am using WSO2 ESB 4.0.3 with Data Services Feature 3.2.2. Proxy service front ends the DS service. Data sources are defined as carbon data sources in datasources.properties.
I tried to run the same service in the WSO2 Data Services Server 2.6.3 and the performance is comparable to what existing tomcat application does but the ESB 4.0.3 with Data Services Feature 3.2.2 takes 8 times more time than tomcat application. Looks like XSLT is not a issue as I thought earlier.
I have all the error handling & input validation in the proxy service which calls this DS.
Also I tried changing it to local for the transport but still same performance issue. Also I have to make sure the format of the forwarded XML is SOAP 12 in the end point definition otherwise proxy service does not forward with local transport.
Can you please suggest so that I can use WSO2 ESB with Data Services Feature 3.2.2 and get comparable performance?
Help really appreciated.
thanks
Abhijit
Hi Prabath
Thanks for reply.
Proxy service validation and transformation is not a problem. Looking at the logs it looks like Data Service deployed in ESB with Data Services feature is taking 8 times more time than the tomcat application. So it is Data Services Feature which is problem I believe and not the proxy service.
Even if we remove the proxy service where you will do the input validations and error handling?
Please let me know.
thanks
Abhijit
Abhijit,
I'm not quite clear of whether this problem is related to executing SQL using dbReport/dbLookup mediators against doing the same thing having data services features installed in ESB OR transforming responses using XSLT at the ESB layer against doing it at the DSS layer.
If it's the former, then you should be able to effectively use the db mediator pair (namely dbLookup and dbreport) to execute simple SQL queries such as SELECT, INSERT, UPDATE, DELETE, etc. However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.
If this is related to the later, meaning, if you refer to the XSLT transformations, I believe there's no such hard and fast rules in doing this and this would completely depend on your requirements and the usecase. For example, if you're only using WSO2 DSS and want to get some request transformed into a particular format that is expected by the client side, it would only be enough for you to get it done at the WSO2 DSS layer. Because, dispatching it into ESB ONLY for the sake of getting the XSLT transformation done, would add an additional unwanted overhead to the end-to-end completion time of your task. On the other hand, if you're doing this as a part of a configuration flow at the ESB side, then it's perfectly okay to use something like XSLT mediator inside the flow itself.
Hope this helps!
Regards.
Prabath
I hope Prabath already gave the answer to your question.
However, it is not recommended to do use those mediators to do much complex queries such as stored procedures with "OUT and INOUT" parameters etc as WSO2 DSS is specifically designed to serve any sort of complex queries like that. However, this (using data services) comes at the cost of network latency. Because, you're invoking a data service endpoint through the network which obviously adds the network latency to the end-to-end time taken to get your task done. However, if you're using Data Services features installed in the WSO2 ESB, you always have the option of using "local" transport instead of "http/https" which does an in-JVM call and thus would not dispatch the request over the network.