In simple http endpoint, how to implement load balancer using any point studio.
<flow name="testFlow">
<http:listener config-ref="HTTP_Listener_Configuration"/>
</flow>
In simple mule HTTP endpoint you cant achieve load balancing.
However there are other efficient solution for achieving load balancing in mule application.
https://docs.mulesoft.com/runtime-manager/dedicated-load-balancer-tutorial
http://www.slideshare.net/ramakrishnakapa/load-balancer-in-mule
Load balancing can not be in simple http endpoint, but you can deploy several instances of your application and balance your request among those instances in mule. Switching between those instances is matter of different algorithms.
In this post it is all described in detail.
https://blogs.mulesoft.com/dev/mule-dev/load-balancing-with-mule/
Related
I have created REST API for POST HTTP and import it to Mule applications then deploy it to CloudHub and used that URL in Shopify Webhook then trying to get data but unable to get data from postman...
Is this a correct way to use Webhook in Mule applications...
Since Mule runtime doesn't has a concept of webhooks there is not a correct or incorrect way to use them. Mule applications can listen to HTTP requests. If another system sends an HTTP request to the correct URL that the Mule application is listening it should work. To the Mule application it doesn't matter if it is coming from a webhook, another application, Postman or whatever HTTP client implementation.
When should we use API Proxy against API AutoDiscovery. After implementing both, I found AutoDiscovery can also apply policies, analytics which API Gateway does, only thing is I cannot use a different url if using AutoDiscovery. Main advantage of API Proxy would be if my Gateway application and Mule Implementation Project is in different subnet, so if we are my Gateway server is compromised, no one can get to my implementation network.
But if both interface and implementation is in the same network, and purpose is just to call a REST Endpoint, should we not go with API AutoDiscovery.
Problems with Mule API Gateway Proxy
No defined way of Exception Handling, if we are not able to reach the Implementation Server.
No defined way of moving the Proxy Application across environments (CI/CD)
Extra HTTP Hops, can be acceptable if the above 2 issues have a defined way
Mule API AutoDiscovery
Since this is in the Mule Application, standard Exception Handling.
CI/CD is defined as it is the Mule Implementation Project.
No Extra HTTP Hop.
Only thing here is, we cannot change the implementation URL, that is only tightly coupled thing.
Can someone provide insight on when should we go for API Gateway vs AutoDiscovery. Also currently is there a way of doing Exception Handling in API Gateway Project and also CI / CD ?
API Autodiscovery is required if you plan to apply/unapply a policy to a particular endpoint, and/or take advantage of usage statistics in the context of API Platform. Api Autodiscovery is kind of metadata that links a HTTP(s) listener to its counterpart API version on API Manager.
For example:
<api-platform-gw:api id="api.basic.path" apiName="My API" version="1.0.0" flowRef="basic.path">
</api-platform-gw:api>
<flow name="basic.path">
<http:listener config-ref="a.http.config" />
<set-payload value="Endpoint successfully called." />
</flow>
Autogenerated Mule Proxies do have autodiscovery defined. You can also develop your own project and define the corresponding autodiscovery either by using the Studio UI, or handling the XML config directly.
The proxies are mean to be used in the case that your implementation backend is not a Mule application (for example, an existing REST based API hosted in a Tomcat server). You can enrich the logic with custom exception handling among other things on the Mule side. If you'd like better exception handling on the implementation backend, you will have to implement it there.
If your implementation backend is a Mule based application, using a proxy is not required. For most use cases, adding the corresponding autodiscovery element in the configuration file will do the trick.
A beginner in Mule and Server deployment, so please help. I have my local apache http web server running and configured the web server settings in a third party application. And the third party application's web service POST HTTP data to web server which I can access in PHP file and view the data.
How to simulate the same in Mule? Is it possible to configure Mule Server as web server in that application? If not can I access the data available in apache web server through any connectors?
Mule comes with an HTTP Connector, so yes it can receive HTTP POST requests.
Reference: https://developer.mulesoft.com/docs/display/current/HTTP+Connector
Yes, Using HTTP connector you can send POST request to the server .
you also wont have to configure the server properties just the port at which you'll access your application.
<flow name="testFlow1" doc:name="testFlow1">
<http:inbound-endpoint exchange-pattern="request-response" host="Server_Address_e.g._localhost" port="Enter_Port_Here" path="Enter_your_path_here" doc:name="HTTP"/>
</flow>
I'm new to Mule and am trying to setup a web server [in Mule] to "replace" an existing Java server - which simply proxies for a SOAP web service.
So:
Web client (js/html) requests a static resource
Mule Server must return the static resource
or
Web client uses Jquery Ajax (json) request with path starting with "api/"
Mule Server must forward the request to the Java server (to use the old API)
or
Web client uses Jquery Ajax request with path starting with "sapi/"
Mule Server must translate the request to XML and call the SOAP server (for new api calls)
I'm struggling to find a good starting point:
I've played with Ajax connectors (and end-points) and can get the static content served - but not sure where to go with the api calls (don't want to force the client app to use mule.js)
I've played with HTTP end points, and I can't get the static content served (implicit Content-Type issue)
Any help will be appreciated...
Use http:static-resource-handler to serve your static content: it should take care of the content types for you. See for more info: http://www.mulesoft.org/documentation/display/current/HTTP+Transport+Reference#HTTPTransportReference-ServingStaticContent%28sinceMule3.2%29
Forget about the Ajax connector, all you need is the HTTP connector. Bind one HTTP endpoint on api and the other on sapi.
When forwarding the request, be sure to propagate headers and, potentially, path extension after api/. See the example below to see how this is typically done.
<flow name="rawProxy">
<http:inbound-endpoint
address="http://localhost:${http.port}/rest-proxies/raw"
exchange-pattern="request-response" />
<copy-properties propertyName="*" />
<http:outbound-endpoint address="http://localhost:${http.port}/rest/#[message.inboundProperties['http.relative.path']]?#[message.inboundProperties['http.query.string']]"
exchange-pattern="request-response" />
<response>
<copy-properties propertyName="*" />
</response>
</flow>
If the SOAP API you're calling as a WSDL then generate a client for it and instead of transforming to XML, transform to the request object it expects.
I have WSO2 ESB and ELB instances installed.
When HTTP request comes to ESB, it opens a socket and waits for response.
But if ELB instantiates new ESB, then response can go to ESB #2 (instead of #1) and find that there is no socket connection. How would I route response to ESB #1?
[EDIT]
I have implemented custom Axis2 transport, which has class CustomTransportListener. There is a List of opened socket connections, which wait for response. This is the reason why only ESB #1 can handle response.
Each ESB in the ESB cluster behind the ELB is the same so it would not matter which ESB node in the cluster serves the request. The purpose of the ELB is to automatically balance the load and make it so that the complexities of the cluster is not seen so it does not provide a way to specify an specific node that should receive the response.
It is not possible to send a request to a specific ESB in the cluster through the ELB because the ELB uses an Round Robin algorithm to dispatch request to the ESB cluster so you can not gurantee that a specific ESB node will get the request. In my opinoin do not think it is a good idea to make the ESB's in the same cluster different from each other :).