If you read our last blog post, summarizing the top 5 features of the Crowd release, you’ll recall we mentioned the flow designer as one of the main features in Anypoint Design Center. Flow designer is a simple, web-based interface for designing Mule applications for Anypoint Platform. In other words, it provides a simplified UI, but with the same power as Anypoint Studio.
In this Training Talks series, Ethan will show us how to use Design Center in Anypoint Platform to rapidly define and implement an integration project using an API-led approach to connectivity. He will combine the API designer and flow designer features of Design Center to build a Mule application.
In particular, you’ll also see how to reuse existing APIs that are shared in Anypoint Exchange, how to create and manage new API projects using API designer in Design Center, and how to use APIs to quickly build implementation applications using flow designer in Design Center.
Demo Video:
Instructions:
Here we see the “Training: American Flights API” that you can access from Anypoint Exchange. Inside this public developer portal, you can test out all of the API calls in real-time. In fact, the API calls that you make will go against real data from the baseUri that’s defined in this RAML definition.
Here, I’m copying the baseUri from the RAML definition, and I’m testing an API call directly in the web browser. You can see if I make a request to an invalid resource endpoint, I get a 404 error indicating that this is not part of the RAML specification that was implemented.
Now, let’s create a flow designer project in Design Center to access this API through this public URL. We’re going to wrap this URL in a new proxy URL that our implementation will provide, so that other people and applications can then call out to this external API. That will demonstrate how you can build microservices in your application network by leveraging existing APIs and combining them together in new ways
Before we implement our new flow, let’s first specify what the new interface should look like in a new RAML specification. That way, we are taking an API-led approach. Now, let’s go back to Anypoint Exchange where we accessed this API portal in the first place, and let’s download the current version of the API and store it to our hard drive.
Next, let’s go to Design Center and log in. Let’s create a new API specification project. We could just type this new RAML specification and its associated files by hand, but we recommend using Anypoint Exchange to help us get started instead. We could import this API specification that we just downloaded from Anypoint Exchange and import that into our project.
We could rename the project’s RAML file and make various changes that you can learn about in our Anypoint Platform: API Design class. In this case, I’m going to change the outer parent flights resource to American. If I wanted to, I could replace these Exchange module RAML fragments with the data type definitions with my own new data type definition. I could also create new examples.
The other thing that we can change in the future is the baseUri. But first, we’re going to implement the solution, and then we’ll replace the baseUri in this API specification with the new implementation’s URL.
For now, we’ll just turn on the mocking service so we can test if things are working correctly with a mocked baseUri. Let’s change the title of this to our own version, and then let’s save this in Anypoint Exchange. Because we got a notification that a previous version already existed, we’re going to change the asset name.
With this new asset name, the API was successfully published to Anypoint Exchange. Now this API is available for other people to start developing with. We can modify the baseUri once we have a live implementation ready.
Now, let’s switch back to Design Center and implement a project that can utilize this API. Let’s log in to Design Center with an Anypoint Platform account, and create a new flow designer project. Let’s hide the tips and rename the flow.
Your team should agree on a coding convention. Although I could name the flows with spaces, I’m going to use the traditional Java CamelCase. Let’s add an HTTP listener that can accept client requests from web clients, and we’re going to decide now on what the access path should be. We’re going to hide or proxy the /flights endpoint and rename it to /american. This way, the HTTP listener will match the API’s specification.
Then we’ll keep all the other default configurations for this HTTP listener. We’ll restrict this listener to only accept GET requests from external web clients. Now let’s use a connector to forward the web client’s request to an external service. In this case, it’s the “Training: American Flights API” connector, which is publicly available through Anypoint Exchange, and is also available inside the flow designer.
You can see that all of the operations that are supported by the “Training: American Flights API” RAML specification are available here in the automatically generated connector. This connector was automatically published through that RAML specification that you saw earlier using REST Connect.
Notice that the external API implements /flights and /flights/ID}, where {ID} can be any integer number that represents a flight ID. This is just one of several public APIs that are available through the Mule training account’s Developer Portal, or through – Anypoint Exchange.
If I make a request to this baseUri in a web browser, you can see that it’s returning live data to me. In addition to just getting all the available flights, with Postman, I can try deleting a specific flight by an ID number. In this case, the training example will give us a message saying that the DELETE operation was successful, but it’s not actually going to modify the database because this is shared by other students, so we just see a text message returned saying the database was modified (but it’s not really).
Let’s return to the flow designer and finish implementing the flow that’s going to call this public “Training: American Flights API.”
One of the really powerful things about the flow designer in Design Center is that you can actually implement a live project just using your web browser in the cloud. Nothing has to be stored on your local computer or network.
In this case, in our flow designer project, we can search in Exchange for connectors to published RAML specifications––which are actually currently implemented. For example, this “Training: American Flights API” connector will give us access to the actual back-end service that services those API requests for American flights.
Let’s call out to this external training “Training: American Flights API” to make a GET request on /flights/ID, where we’ll provide the ID as an integer so that the external service can do the lookup and return the results back to us.
The connector is telling me that I need to have an ID specified, which means I have to modify the HTTP listener to change the inbound resource URL, and in order to also have the web client include an integer value for the ID as a URI perimeter. If you go back and look at the API that we created in Design Center, that also included this URI, American.(any integer ID}.
Then in the next component, I’ll copy that received URI perimeter for the ID and pass that into the outbound request to the “Training: American Flights API” connector. Now, all we have to do is click ‘deploy’ and wait for the Design Center project to deploy.
Now that the project is deployed, we can copy the link to that HTTP inbound listener and then test this deployed Mule application with a web client like a web browser or, in this case, a Postman.
Remember that our HTTP listener only implements the GET HTTP operation, not DELETE, so let’s change the operation from DELETE to GET in Postman and try again. You can see that our request to /American/two is being proxied to the public “Training: American Flights API” URL on /flights/two. Here you see the response from /flights/two is proxied through our connector, and returned to the web client on the URL /American/two.
Now that we’ve tested that the deployed Mule application is working up in the cloud, let’s copy the final result JSON data and use that to do some more data transformation inside our flow.
For example, if we were using another connector like a database connector, the result might be a Java object rather than JSON; so we can set the type to arbitrary JSON using this empty JSON example. That would automatically convert from Java to JSON. Or, we can paste in the response that we found from the external API and use that to build a JSON example that we can use to help us visually map the transformation.
Now we can drag and drop from the connector response to our desired transform data schema using the data example we’ve copied. Besides just visually drag-and-dropping in the UI, you can switch over to the advanced script mode and unleash the full power of the DataWeave language.
That concludes this quick introduction to the new Anypoint Design Center – flow designer capabilities, where you can merge together your API projects with actual Mule applications that you build in a web browser in the Cloud and deploy it to the Cloud too. You also saw that you could leverage those APIs using REST Connect, which automatically creates connectors for REST APIs. You can do the same for your private APIs too!
Learn more about Anypoint Designer Center- flow designer and take your DataWeave skills to the next level by taking one of our training classes, such as Anypoint Platform Development: DataWeave.
Have questions for the Training team? Drop it in our forum or Training Twitter using the hashtag #TrainingTalks and stay tuned!
Learn more about our available courses and certifications by visiting our training site.
