Nav

Lab 1: Implement the Omni Channel API in Studio

Overview

In this first lab, you will use Anypoint Studio to create a Mule application where there will be one flow for each method of each resource (i.e. GET). Additionally you will use APIKit (as part of your Mule application) to process each REST requests, transform them to messages to be handled and processed by each flow.

The implementation will consist of a few steps

  1. Create a new Mule Project in Anypoint Studio from the Omni Channel API RAML

  2. Run the Mule app from Anypoint Studio

Then we will test this new API using the API Console.

Step 1: Create a new Mule Project from the RAML

In this step we will create a new Mule application in Anypoint Studio from the Omni Channel API RAML Definition. This will be the implementation of our REST API.

  1. Start Anypoint Studio from the desktop icon.

    module2 lab1 step1 1 studio logo
  2. You are presented with the Anypoint Studio 7 Welcome Screen.

    module2 lab1 step1 2 welcome screen
  3. Click through the "What’s new" items and click Go to Workspace.

  4. In the Workspace Launcher, use the default workspace directory location.

  5. From Anypoint Studio’s menu, select File > New > Mule Project to create a New Mule project. A Window will pop-up to define the details of this new application.

    module2 lab1 file new
  6. Give the project the name omni-channel-api-v1-0

  7. Select the Mule Server 4.1.4 EE.

  8. Under API Implementation settings, check Specify API definition file location or URL and choose Design Center…​ by clicking in the (…) button on the right of the Location textbox.

    module2 lab1 new mule api project
  9. Once you clicked there, it should take you to the Browse Design Center for APIs window, if it asks you to login, use your Anypoint Platform account.

    module2 lab1 platform login
  10. Select the workshop business group.

  11. Select the <username> - Omni Channel Experience API that you created in Module 1 and click Ok. If you can’t find your API, click through the different Business Groups. You can also search for your API using the type filter text field. (you may have more API Definitions showing in this window)

    If you don’t see the API, press Load more projects. This link only appears when there are too many projects on the API Designer.
    module2 lab1 step1 6 browse design center apis
  12. Now click Finish. This will create a skeleton project that implements your API.

    module2 lab1 step1 7 studio overview

    Let’s explore what was automatically generated.

  13. At the top of the diagram you will see a flow called api-main and api-console followed by flows, one for each method defined in the RAML.

    The flows below are defined by your API Design in the RAML file. Typically, there will be flows that look like this get:\resource, post:\resource, put:\resource, etc. Note that the name of the flow is very important for the APIkit router to be able to route the request to the appropriate flow - you don’t want to change these.

    When APIkit detects example data in the response of a method in the RAML it inserts a Dataweave Transform Message into the flow which returns the static response specified by the example data reference.

    The static response returned by the auto-generated Dataweave Transform Message allows you to test the API as a stub immediately after generation. Obviously these flows can be enhanced to provide more advanced mock services as well as evolve them into full API implementation as we will see in the next lab.

    module2_lab1_step1_8_apikit_main

    api-main
    This is the main flow. It exposes an HTTP service and processes the requests using the APIKit Router.

    The HTTP request will be converted to a mule message, and redirected to the requested flow by the APIKit router.

    By selecting the http listener one can take a look at the HTTP configuration, you will see that its listening for requests on http://localhost:8081/api.

    Inside the api-main flow also an Error-Handling block is included. In this block multiple On Error Propagate definitions are autogenerated for common API error responses such as METHOD_NOT_ALLOWED, BAD_REQUEST etc.

    module2_lab1_step1_9_apikit_put_user_shopping_cart

    put:\users\user{user_id}\shopping_cart
    This flow puts an item into a users shopping cart based on the user id. This put operation returns no response and therefore the Dataweave Transform Message processor is replaced automatically by a Logger message processor.

    module2_lab1_step1_10_apikit_get_order_by_id

    get:\orders\order\{order_id}
    This flow gets an order based on an order id

    module2_lab1_step1_11_apikit_get_product_by_id

    get:\products\product\{product_id}
    This flow gets a product based on a product id

    module2_lab1_step1_12_apikit_get_order_search

    get:\orders\search
    This flow returns orders based on search criteria

    module2_lab1_step1_13_apikit_get_product_search

    get:\products\search
    This flow returns products based on a search criteria

    module2_lab1_step1_14_apikit_get_user_shopping_cart

    get:\users\user\{user_id}\shopping_cart
    This flow returns all the items in a users shopping cart based on a user id

    module2_lab1_step1_15_apikit_post_shopping_cart_confirm

    post:\users\user\{user_id}\shopping_cart\confirmation
    This flow confirms the items to purchase in a users shopping cart.

Step 2: Test the Generated API Project

  1. To test the API, let’s run it within Studio first. Right click the application.

  2. Select Run As > Mule Application.

    module2 lab1 step2 1 studio run as
  3. The application will start running, and the console will show the Mule Runtime logs

    module2 lab1 step2 2 studio console deployed
    Anypoint Studio deployed this application to an embedded Mule Runtime. There is no need to deploy to a separate Mule server environment. The developer will be able to develop and test the application locally until it’s ready to be deployed to a shared development or QA environment.
  4. Test the application using the console. Click button Open Console on the APIkit Console tab.

    module2 lab1 step2 3 apikit console base url
  5. A browser window opens at: http://localhost:8081/console/.

  6. Click open the /products/search resource on the left and click GET.

  7. Click the TRY IT button on the top right to submit the request.

    module2 lab1 step2 4 browser apikit console tryit
  8. Then tick the Show optional parameters and fill them in as below and click SEND.

    module2 lab1 step2 5 apikit console get request

    The response will show mocked data that is defined in the imported RAML.

    module2 lab1 step2 6 apikit console response

    It is a live application deployed to the Mule runtime server but it is leveraging the RAML information to provide a “mocking” experience.

    Let’s go ahead and stop the application to get ready for the next lab.

  9. Go to the console tab and press the red squared button to stop the Mule runtime server.

    module2 lab1 step2 7 studio stop

Summary

In this lab, we

  • Downloaded the API definition directly into Anypoint Studio.

  • Used the RAML specification to generate the initial implementation skeleton for the API.

  • Auto-generated a skeleton project to implement the API.

This lab shows how APIkit quickly allows developers to import the designed REST API (RAML and supporting artifacts) to enable rapid API logic implementation in the generated MuleSoft flows. The APIkit also deploys the interactive console with the MuleSoft flows. The lab shows the extent to which a developer can deploy an on-premise and interactive API from the API specification in RAML.

It is important to note that the implementation of an API is a real MuleSoft application and allowed us to test the end-to-end API. Building integration applications and exposing APIs do not require additional knowledge making it easy for MuleSoft developers to work on both integrations and APIs.

Congratulations! You have completed Lab 1.

Please proceed to Lab 2