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.
Related
I have a WinForms application and I want to receive inbound SMS using Twilio. I am using VB.NET. The code that I find on the Twilio website are using web application and MVC. Can anyone help me how to use it in WinForms?
Did not get enough to try out anything.
Twilio uses a standard way of notifying your service, called webhooks. When an SMS, phone call, or something else happens, and you configure a webhook for that, Twilio will send HTTP requests to the URL configured as a webhook.
This does mean that you have to have a publicly running web server that can accept those HTTP requests with the details of the SMS, phone call, etc. That's why the samples will use ASP.NET, as this is only possible with web technology.
Winforms runs on your computer and doesn't expose any public web endpoints to receive the webhook HTTP requests, so you can't receive it directly. However, depending on your use-case, you have options.
If you don't need real-time updates, you can read the message history using the Twilio C# .NET SDK.
In your winforms app, you could add a button to refresh the messages on click. Alternatively, you could query the message X amount of seconds to give it a more real-time feel, even tho it's not really real-time.
Warning: to use the Twilio API to get the messages, you'll need to embed the Twilio credentials into your Winform app. Anyone that has access to your app will be able to read those credentials. Keep that security risk in mind!
The second option is to use ASP.NET to receive the webhook HTTP requests, and then use a SignalR or websockets to notify any connected clients, of which your winform app would be one.
For example, when Twilio receives an SMS, the ASP.NET application receives the webhook HTTP request, the ASP.NET app then send the SMS details to all clients connected to your SignalR hub, and then your Winforms app receives the SMS payload which you can use to render your app.
The second option is a lot more work and requires more infrastructure since the ASP.NET app needs to be hosted somewhere. We don't have a tutorial for that, but I'd be happy to forward more links to docs etc. if you have questions.
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?
Trying to identify worklight adapter requests from web server access logs, but all the requests look really generic. Any idea how to identify adapter requests?
The Request only contains "POST /Worklight/apps/services/api/MobileApp/android/query HTTP 1.1". I
can't see the adapter name nor procedure name.
while this query is indeed an adapter invocation , the adapter name, method and parameters are embedded into the POST HTTP message body. its not a big payload (less than 1KB).
I'm not an IHS log expert, but maybe there is a way to log also message body.
( I saw this un-answered: https://stackoverflow.com/questions/27354942)
However, if you upgrade to newer MFP version (v7.0+) then you can expose adapters as a RESTfull service. This will make the IHS logs much more clear which adapter was called (each one has different URL).
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?