salesforce
+
+

Lab 2: Overview of Anypoint Exchange - Part 1

Overview

APIs are the reusable assets that simplify and accelerate the creation of modern software applications. As a MuleSoft developer, you will need to consume APIs created by other organization members and publish new APIs for others to consume. This new consumption model is the foundation of a new approach for delivering software solutions where APIs form the building blocks of the modern enterprise.

This lab exercise focuses on using Anypoint Exchange to search for APIs and other assets published for others to reuse.

Learning Objectives

  • Become familiar with the various assets you can store in Anypoint Exchange.

  • Learn how to find an API and test its behavior before you decide to use it in your application.

  • Learn how APIs may be shared via a public portal, enabling developers outside your organization to access them.

Step 1: Login to the Anypoint Platform

  1. If you are not logged into the Anypoint Platform, open your web browser and navigate to https://anypoint.mulesoft.com.

    lab02 login

  2. Enter your credentials into the Username and Password fields.

    lab02 login2

  3. You should see the Anypoint Platform landing page once logged in.

    lab02 anypoint landing

Step 2: Access Anypoint Exchange

  1. Click on the button labeled Discover and share, or click on the hamburger menu, and click on Exchange.

    lab02 discover and share

  2. You should see the Anypoint Exchange landing page.

    lab02 exchange landing 1

    The screen capture above is for illustrative purposes and differs from the landing page seen in the workshop.

Step 3: Review the Features of Anypoint Exchange

As a reminder, Anypoint Exchange is a curated catalog of reusable assets such as APIs, policies, API spec fragments, API groups, templates, examples, custom assets, and integration assets such as connectors. You, your team, and your larger organization can catalog, publish, share, discover, learn about, and reuse assets within your organization to facilitate collaboration, boost productivity, and promote standards. Hence, Anypoint Exchange should be your initial starting point for most, if not all, projects.

For example, as an API consumer or client, Anypoint Exchange is where you should start if you want to use an existing API. As another example, as an API provider or producer, you should search Anypoint Exchange to see if there is an existing API or even other types of assets you might be able to reuse before creating a new API. Sometimes you will find that someone else has already undertaken the task of creating the API or has shared other types of assets that you could reuse to jumpstart your undertaking.

  1. Anypoint Exchange organizes assets by categories as illustrated in the following screen capture.

    lab02 exchange landing 2

    The visible categories vary slightly depending on the organization (and its business groups) and the current business group. For example, in the screen capture above, the MuleSoft developer works for Badger, and as indicated in the top right corner, the current business group is Sales. As such, the categories shown include:

    • All assets includes all assets from all categories.

    • All Badger includes all assets any developer created and published at the organization level. Assets created by any member of an organization are private by default and not visible outside that organization. In this example, the organization is Badger.

    • Sales represents the current business group and includes all assets created and published in this business group. Similarly, assets created and published in a business group are private by default and not visible outside that business group.

    • Provided by MuleSoft includes assets created by MuleSoft and its partners and certified by MuleSoft. These assets are publicly available to all MuleSoft customers.

    • Shared with me includes assets shared explicitly with you. More specifically, Anypoint Exchange administrators and asset administrators can share an asset with a user or team in their organization, the whole organization, or an external organization.

    The All assets category is selected in the screen capture above. You can click any category (or link) to filter assets.

    Anypoint Exchange includes access control capabilities to restrict access to categories as needed. As an example, organization administrators can restrict organization-level access and leverage business groups instead. For example, a developer within the Sales business group cannot access the R&D business group, and vice-versa.

  2. The left navigation menu includes two additional options.

    lab02 exchange landing 3

    • My applications list client applications registered in the organization that hold contracts with an API or an API Group. Client applications that appear here are typically registered at runtime using Anypoint API Manager.

    • Public Portal enables you to create, customize, and manage a public developer portal for your organization. Please note that a public portal is visible to anyone who has the URL of the portal. By default, the public portal is not enabled. Furthermore, you must explicitly mark APIs and assets as public for them to appear on the public portal.

Step 4: Search for an API in Anypoint Exchange

This step walks you through a predefined sequence using a generic Anypoint Platform account. Please feel free to follow along in your workshop account, but remember that the screen captures may differ.

  1. To search for an API or any other asset, first, you need to select the category to search. In the following example, we search within the All assets category.

  2. Next, you enter one or more keywords in the search bar. In the following example, we search assets with the keyword manufacturing in their name, tags, description, etc.

    lab02 exchange search 1

    As illustrated in the screen capture, the search results include all types of assets.

  3. Noticed the All types dropdown list, which enables us to search or filter only for a specific asset type.

    lab02 exchange search 2

    The types of assets as of this writing include:

    • Connectors are self-contained components that allow you to integrate Mule applications and APIs with external and third-party applications such as Salesforce, SAP, and Twitter.

    • Templates are packaged integration patterns built on best practices to address common use cases. You can leverage a template as-is, customize or extend it as needed.

    • Examples are applications ready to run in Anypoint Studio demonstrating a use case or solution.

    • Policies are configuration modules that extend an API’s functionality primarily for management purposes and enforce capabilities such as security.

    • API Groups are a set of APIs bundled into a single asset. Instead of requesting access to multiple APIs to satisfy a use case, a developer can access the group in one step.

    • REST APIs are RAML or OAS files that specify RESTful APIs.

    • SOAP APIs are WSDL files that specify SOAP (Simple Object Access Protocol) APIs.

    • DataWeave Libraries are packaged DataWeave scripts reusable across Mule applications and APIs.

    • AsyncAPIs are AsyncAPI specification files that describe and document event-driven APIs and message-driven APIs.

    • HTTP APIs represent placeholders in Anypoint Exchange for developers who want to manage endpoints with API Manager, but the actual endpoint might be running in a third-party runtime.

    • API Spec Fragments are any RAML document that has a version and an identifier but is not in itself a complete RAML specification. API spec fragments are also known as RAML fragments.

    • Custom are optional files primarily for documentation purposes - e.g., explain aspects of a system, provide instructional videos, document common use cases.

    • Rulesets are collections of rules or guidelines you can apply for governance purposes. Some examples of governance rulesets are best practice guidelines, naming conventions, industry-specific government standards, or ensuring sensitive data is encrypted.

  4. In the dropdown list, we select REST APIs. The search results are filtered down to include assets of this type only.

    lab02 exchange search 3

  5. Click on any tile. We click on the tile named MFG Salesforce Orders System API in the following example.

    lab02 exchange search 4

    You should now see the API’s specification and its documentation.

Anypoint Platform provides many capabilities and features to make it easier to document APIs. Anypoint Exchange includes capabilities and features to produce rich and comprehensive API documentation. For example, Anypoint Exchange parses the API specifications, including the title and description elements, to jump-start the creation of APIs' documentation. For example, you are not limited to the structure created from parsing the API’s specifications. You can add additional documentation pages as you see fit. When authoring and updating documentation, Anypoint Exchange offers a WYSIWYG editor to author text and add hyperlinks and media (e.g., images, videos). Anypoint Exchange also supports Markdown, a lightweight markup language.

As a developer, your goal is to provide enough documentation to enable self-service. As in most development projects, the more detail you add to an API’s documentation, the more likely there will be more consumption and reuse of the API. API consumers should be able to read the documentation, test your API, and determine if it matches their needs without contacting anyone or opening a ticket, for example.

Step 5: Explore an API in Anypoint Exchange

Anypoint Exchange also provides several features to support and encourage discovery and collaboration. In this step, we explore some of those features using the MFG Salesforce Orders System API as our example. Feel free to open this API in Anypoint Exchange and follow along.

lab02 exchange search 4

MuleSoft product engineering created a new user interface (UI) version, which is the version used for the screen captures in this step. Assuming you logged in to Anypoint Platform, which you should for this workshop, you can switch between the new UI and the previous UI anytime.

As a side note, Anypoint Exchange is available publicly on the internet without having to log in to Anypoint Platform. The assets listed, however, are limited to the public ones. More to the point, the public exchange uses the previous UI and does not include the buttons to switch back and forth to the new UI.

  1. The top left corner displays the asset’s (human readable) name and some basic information.

    lab02 exchange features 1

    • REST API indicates the asset type.

    • MuleSoft represents the organization’s name within Anypoint Exchange where the asset is published.

    • Updated 2 months ago (obviously) indicates when the asset was last updated. Anypoint Exchange displays the actual date and time when you hover the mouse pointer over this field.

  2. The top right corner includes operations you may perform on the asset and its versioning information.

    lab02 exchange features 2

    • The operations you may perform on an asset vary based on the asset type and your security privileges. For this example, as the asset type is REST API, the following options are available:

      • The Download dropdown list enables you to download the REST API as a RAML specification, an OAS specification, or a Mule connector.

      • The View code button opens the REST API’s specification in Anypoint Design Center in a new window.

    • Similarly, the versioning information varies slightly based on the asset type. For this example, as the asset type is REST API, the following versioning information is displayed:

      • The View versions button opens a pop-up window showing the patch versions of the asset. This button is available for most asset types.

      • The v1 label indicates the API version, which is generally defined within the API specification. This label only appears for API asset types - e.g., REST API, SOAP API, AsyncAPI, HTTP API.

      • The Private label indicates this asset is not published or available on the organization’s public portal.

      • The 1.0.x dropdown list shows all available minor and major asset versions.

      • The Latest label indicates (obviously) the latest or most recent version of the asset available.

      • The Stable label represents the lifecycle state of the asset - i.e., Development, Stable.

      • The Not Validated label indicates if the asset has been validated against any governance ruleset.

  3. The middle section also displays content that varies based on the asset type. In this example, it displays the page or the API specification part selected in the left navigation menu - i.e., the content of the Home page.

    lab02 exchange features 3

    Although the documentation of this REST API includes a single page, as a reminder, you can add as many pages as you see fit when documenting your API.

  4. The bottom section shows all reviews of the asset, and it also enables us to write a review. Unfortunately, our example, the MFG Salesforce Orders System API, has not received any review yet.

    lab02 exchange features 4

  5. As mentioned already, the left navigation menu dictates what the middle section displays. For most asset types, the navigation menu only includes pages. However, for some specific types, such as REST APIs, API Spec Fragments, and Policies, it includes a lot more information derived automatically from the asset.

    lab02 exchange features 5

    • The SPECIFICATION section contains a lot of information derived from the API specification. Naturally, as seen in the screen capture, this information includes the endpoints (and resources), the (data) types, and security-related specifications. In many cases, the content is also enriched using the title and description elements of the specifications (. assuming the developer included them). Feel free to expand the different options and explore the various documentation pages.

    • For asset types that include it, the OTHER DETAILS section does not always contain information. For a REST API, however, the API Instances option shows the managed API instances if any. If none, it shows the available mocking services, which we will explore next.

Step 6: Test an API via the Mocking Service

A handy feature available in Anypoint Exchange is the API mocking service, which simulates the behavior of an API specification. As we will explore, the API mocking service returns the responses defined in your API specification, both HTTP status codes and example payloads. You can use the API mocking service in Anypoint Exchange or call it using your favorite API testing tool (e.g., SoapUI, Postman).

Most importantly, the API mocking service enables you to focus on designing your API specification without having to code anything. Furthermore, it allows consumers to interact with the API as if it was implemented and deployed. As a benefit, this feature enables you to rapidly iterate the API design with input from its consumers to finalize the API contract. As a second benefit, the API mocking service allows parallel development between API providers and API consumers - e.g., an API consumer can test their client application immediately and do not have to wait for the API implementation.

Please note that this step continues where we left off in the previous one.

  1. Click on API instances on the left navigation menu. Notice that there is a single instance, an API mocking service.

    lab02 mocking service 1

  2. Click on Summary on the left navigation menu, and click on the Get operation of the /orders/{orderId} endpoint.

    lab02 mocking service 2

  3. The middle section is updated and shows information about the endpoint - e.g., the API supports Basic Authentication, and the URI parameter orderId is required. More importantly, the API mocking service is located on the left side.

    lab02 mocking service 3

    You can copy the URL of the API mocking service to simulate this API using your favorite API testing tool.

  4. In the API mocking service, we enter any value for orderId.

    lab02 mocking service 4

  5. Then we scroll down, enter any value for user name and password, and click Send.

    lab02 mocking service 5

  6. The API mocking service returns a sample response, including an HTTP status code and an example payload.

    lab02 mocking service 6

  7. We are done investigating this API. Finally, we return to the assets page by clicking on the Back to assets list link in the top left corner.

    lab02 mocking service 7

As an API consumer, the API mocking service is a handy feature of Anypoint Exchange that enables you to investigate an existing API and determine if you might be able to reuse it before creating a new API.

Step 7: Review the Public Portal

This step shows how to access shows the Public portal. However, the primary screen was captured in a preconfigured Anypoint Platform demo account. Please feel free to follow along in your workshop account even though the screen captures will differ.

As discussed earlier, the Public Portal option enables you to create, customize, and manage a public developer portal for your organization.

  1. We click on Public portal on the left navigation menu.

    lab02 public portal 1

  2. The following screen capture shows an example of a Public Portal.

    lab02 public portal 2

    At a minimum, the Public Portal shows the asset pages with the search bar. The public portal’s assets page offers most (if not all) of the same features and functionality we explore in the previous steps - e.g., enables you to search for a public API, explore it, test it with the API mocking service, and ultimately determine if you might be able to reuse it before creating a new API.

    Exchange administrators can tailor the appearance of the Public Portal to match your organization’s preferences and add additional pages as needed to provide comprehensive documentation about the portal and the public APIs offered.

Summary

This lab exercise focused on Anypoint Exchange. It guided you through foundational features and capabilities for simplifying and accelerating the creation of modern software applications through better collaboration and increased reuse, as examples. The following lab exercise will focus on Anypoint Design Center - e.g., designing an API specification.

Proceed to Lab 3: Overview of Anypoint Design Center to continue.

Submit your feedback!
Share your thoughts to help us build the best workshop experience for you!
Take our latest survey!