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.
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.
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/
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 tried to use mule as simple http proxy but seeing cookies that are send from the actual endpoint server is not passed on to the the client. Mule response has only one cookie.
<flow name="HelloWorld" doc:name="HelloWorld">
<http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8888" doc:name="Http Endpoint"/>
<http:outbound-endpoint
method="GET" exchange-pattern="request-response"
address="http://www.google.com"
contentType="text/html" doc:name="HTTP" />
</flow>
I think your problem is not passing the cookies to the client, but the fact that the cookies you receive will point to .google.com domain, so a basic web browser will probably reject them for security reasons when they come from localhost domain, and even if they were not rejected, they would not be sent along a subsequent call to localhost.
Now, the cookies come from the http outbound as a list that you can iterate and update with something like
#[foreach (cookie: message.inboundProperties['Set-Cookie']) {cookie.domain='localhost'}]
but you will also need to check for the existence of Set-Cookie property to not produce a null pointer exception when no cookies are set by the server.
for debugging your proxy app, you can/should also log the message you receive from the http outbound to see if cookies are present.
From the client/browser to the proxied server, I think the cookies should work just fine, as there is no domain data involved.