Hi I am working with Mule Studio and i am successfully running my flow in Mule Studio. I have certain issues related to implementation level since i have multiple flows in the one project.
How to deploy Mule as a REST Service with the existing flow.
If i am deploying my Mule as a REST Service what are the inputs i have to provide to make it run from the external HTTP Client based program.
When to use HTTP Client and when to use Mule Client. Which one fits where.
you can make use of RAML
1.create a RAML and generate the flows which internally referes your current flows
you can configure the Http details in generated flows
why you want to use http client and Mule client in your flows?
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.
I have a mule service, named IS, deployed on mule runtime and proxied on API gateway. I'd like to set up different policies to the IS and its proxy service. How can I do it?
My environment:
Mule runtime: 3.7.4
Mule API gateway: 2.1.1
The following are two valid and equally correct solutions that you can choose from, taking into account that your implementation API is a Mule app:
Create an API on API Platform
Solution A:
Configure the autogenerated proxy to use your implementation API URL
Deploy the proxy to a correctly configured API Gateway/Mule runtime
>= v3.8.0
Apply one or more policies to the tracked proxy
Solution B:
Add autodiscovery to your implementation API, using the same API
name and API version name than your already created API on API
Platform
Deploy the impl app to a correctly configured API
Gateway/Mule runtime >= v3.8.0
Apply one or more policies to the tracked implementation app
With solution A, you have to make sure that your implementation app is only accessible by the proxy app (eg with a firewall).
If your implementation API would not be a Mule app, then Solution B would not be possible.
We can create endpoint with a proxy or select Basic endpoint if you create your API outside API Manager, for example, you created the API using Mule ESB. You don’t need a proxy in this case. So policies will be applied to API. For more details go through the link.
https://docs.mulesoft.com/api-manager/setting-up-an-api-proxy
If you're using Mule runtime v3.8.x, and if the service is an HTTP/S listener, you can actually make it auto-discovered in the API Manager and have policies applied directly on it, even if the mule config is not generated using APIkit.
https://docs.mulesoft.com/api-manager/api-auto-discovery
Choose the flow that you want the API Manager to manage and apply policies.
Do note that you will need to have to right entitlement (API Gateway) in the Mule Runtime license and that it has the right Anypoint Platform Client ID/Secret pairs configured in the wrapper.conf. The IDs should be automatically configured if you've added the Mule Runtime server in the Anypoint Runtime Manager.
Here is my solution to apply policy to proxy service:
Create a new API using proxy service's url
Apply policy to API created in step1
Can anyone confirm this is the correct way?
Why do we have SOAP connect option while creating a connector when we already have a Web Service Consumer connector? We can configure a wsdl with Web Service Consumer and access a web service. What is the difference between the two options?
"Why do we have SOAP connect option" because MuleSoft want to provide a method for ISV to provide connectors to new and existing endpoints without Mulesoft themselves having to create them. Mulesoft Anypoint Platform success is built on the premise of connecting to anything and therefore SOAP Connect helps this.
Secondly connecting to a using WSDL location for consuming a soap web service involves a developer to know the service pretty well and therefore allowing error and interpretation errors but if you internally create a connector you can reduce implementation time and errors.
Thirdly on WSDL there are often many methods not applicable or and an enterprise does not want to consume and therefore a connector can filter these methods.
Connectors = Re-Use
Web Service Consumer connector = manual process
The Web Service Consumer is an existing connector that you can configure to point to a WSDL location for consuming a soap web service. SOAP Connect is a DevKit wizard that creates an Anypoint Connector that connects to a specific service, which can expose multiple WSDLs of the service.
With Web Service Consumer we have to call each API separately in separate flows. With SOAP Connect, you can package multiple WSDL files and API versions into a single connector, making the process of creating, maintaining and using a connector for SOAP APIs much faster and easier.
I would like to know if deploying APIs designed using RAML and API-kit in the studio on Mule Enterprise Server for ESB ver. 3.6 is a good idea?
Our organization is interested in using Mule ESB 3.6 for integrations and we thought of recommending using RAML and API-kit for REST API design and development. We are not interested in any Gateway features but would like to leverage RAML for API definition.
Has anyone experienced any issues if we go for a Mule ESB 3.6 Enterprise and deploy these REST APIs designed using API-Kit and RAML there? Is this design approach specifically meant for the API Gateway which is part of the Mule Any-point API Product offering?
API Gateway (AGW) is a superset of Mule EE. RAML and APIKit are not tightly coupled to API Gateway or Mule ESB but can work in either of them. In the case of AGW, APIKit comes bundled with it, while with Mule ESB you have to provide the jar yourself or develop your APIKit project on Mule Studio (using the APIKit Mule Studio plugin) and export the project from Mule Studio when ready.
The advantage of using AGW is that you can develop your APIKit project as usual, and then be able to apply-unapply high end policies to it at runtime (OAuth security, XML Threat protection, IP Blacklisting, etc, etc).
I have used this REST API using RAML for my client. They didn't face any issues and it's working perfectly. And it's easy to implement.
I see no problem in doing what you are suggesting. Gateway and such are services build on top of Mule and RAML technologies -- if you choose not to use them you'll just lose the features they offer but again RAML, Mule, and APIkit work just fine on their own!
In latest version of mule brought many features like api auto discovery and there is no separate gateway and runtime they have been combined together as a single component.
Api auto discovery allows us to apply policies on top of original implementation api.
you can create proxy for the original implementation and policies can be applied on the proxy layer which is in gateway.