This example call from postman to mule app, then call to northwind api with dynamic entity type (Customer, Orders, etc) and dynamic query string. The dynamic part is achieve using url placeholder and mulesoft attributes. We will see mulesoft debugger very helpful able to see all the underlying fields values when request send to mule app. Final result is return odata query result back to postman.
Before build the mule app, below is direct call to northwind api using postman. Next we will going to build mule app to do similar call.
the mule flow, an listener to receive http call, then a request step to call to northwind api.
Listener step:
The path of listener have an url placeholder {entityType}. At runtime, {entityType} will be replaced with actual value ‘Customers’ or other value such as ‘Orders’. This dynamic behavior allow to reuse same mule http listener for different call.
/northwind/api/{entityType}
Request step:
Here we construct the request path with attributes.uriParams and
attributes.queryString. At runtime these attributes will be dynamic value send from postman.
'/' ++ (attributes.uriParams.entityType as String) ++ '?' ++ (attributes.queryString as String)
HTTP Request configuration:
host = services.odata.org
Protocal = HTTPS
Base path = /V4/Northwind/Northwind.svc
Before test run from postman, it is good to set breakpoint on step we interested. Here we toggle breakpoint on ‘Request’ step, then able to see ‘under the hood’ this step.
Test run from postman with this full url. Notice that after click ‘Send’, result is not immediately returned, but stuck with ‘Sending…’, because now the processing entering mule debugger, as we had set the breakpoint.
http://localhost:8081/northwind/api/Customers?$filter=Country eq 'UK'&$count=true
At mule debugger, we can see all params/fields of ‘Request’ step, and also ‘attributes’ relevant fields. At here we’re interested with ‘attributes.uriParams’ and ‘attributes.queryString’ because these two are used in Request step.
Beside above debugger, we can also set the dataweave expression that we’re interested in ‘DataWeave Expression Watches’. Here set these two expression, then during debugging, can see the what values they are.
At mule debugger, press ‘F6’ to continue the debugging to next step. Since we only set one breakpoint only, so the processing continue till the end. Now back to postman again, result is return in postman.
Did another test run, this time change {entityType} to ‘Orders’. Filter change to ‘ShipCountry’. Below show the query response.
http://localhost:8081/northwind/api/Orders?$filter=ShipCountry eq 'UK'&$count=true
If look at mule debugger, listener path remain the same, but entityType and queryString changed.
listenerPath = "/northwind/api/{entityType}"
attributes.uriParams.entityType = "Orders"
attributes.queryString = "$filter=ShipCountry eq 'UK'&$count=true"
So above a simple walk through of flow from Postman to mule app to external northwind odata, then back to postman again. This serve as foundation to build even more complex flow. In actual real-life scenario, many time will need to make call to external api to fetch some data, then further enrich existing source payload by combining data from external api.
A crucial part that always comsume developer lot of time to develop and debug is the complex mapping part, will look into that in dataWeave and transform message step.
Cheers!