Nav

Anypoint Platform Upgrade to Latest Software Guide

The upgrade to the November 2017 or "Crowd" release changes the existing Anypoint Platform APIs, which affects continuous integration and continuous development (CI/CD) pipelines built against the API Manager API and autodiscovery. See the APIs in API Manager - Post-Upgrade and CI/CD Changes to Make sections. A high-level overview is in the CI/CD Architecture section.

Note: After the upgrade and before classifying your APIs into environments, test your APIs, Notebooks, and Portals. After APIs are classified, your organization cannot roll back in the event you encounter upgrade related issues.

To Complete Upgrade to November Release

Anypoint Platform provides these steps to complete the upgrade to the November 2017 Anypoint Platform software release:

  1. Group your APIs. (Optional, recommended)

  2. Request a time to upgrade using the green banner that lets you access the self-service upgrade portal. Only the organization owner can schedule the upgrade. If you do not see a banner, contact your Customer Success Manager to coordinate steps to upgrade.

  3. After the upgrade, we recommend you classify APIs to your environments. (Optional, recommended).

Before the classification step, test your APIs, Notebooks, and Portals. After APIs are classified, your organization cannot roll back in the event you encounter upgrade-related issues.

Why Group your APIs?

Grouping your APIs helps you organize your APIs by name and version in the new platform experience and improve how you deploy these APIs to environments.

Note: If you use Business Groups instead of environments to group your APIs, API grouping is not needed or recommended.

The November 2017 version of the platform supports APIs that are assigned or classified into environments. Prior to the release, you may have stored the name of the environment in the name of the API.

For example, the "Customer API" may have had "Staging" or "Prod" in the name to indicate use in those environments:

Customer API Staging - v1
Customer API Staging - v2
Customer API Prod - v1

If you labeled your APIs or versions using the names of your environments, consider renaming your APIs before scheduling your upgrade. After the upgrade, each API is associated to a single Design Center Project with a corresponding Exchange asset per API version. By removing the environment name you avoid having extraneous Exchange assets.

After the upgrade, you will be able to see the original API names so you know which to deploy to each of your environments.

Notes:

  • If you do not perform the grouping step, you may find duplicate projects or a degraded platform experience.

  • After you add one or more APIs to an API group (New API Name in the API Grouping screen), you can’t ungroup the APIs. However you can change the group for each API individually to direct it to a different API group, by changing an API or API version name.

To Group your APIs

Note: Read the previous To Complete Upgrade to November Release and Why Group your APIs? for vital roll back and business group information.

We recommend completing grouping your APIs before scheduling your upgrade to remove the name of the environment (dev, stg, etc.) and clean up API names or versions. After the upgrade, you can promote or "classify" an API version into an environment.

  1. Log into Anypoint Platform and go to API Manager.

    To the right of each API in API Manager you should see a message that reads Prepare To Group. You can click Edit to change the New API Name, New API Version, or to include or exclude your portal. Important: Only one API portal can be migrated for a group of APIs.
  2. Click Prepare To Group to add an API to a new or existing group. On the Group an API screen, API Manager lists the Current API Name and Current API Version.

  3. Specify a New API Name. This can be any string of ASCII characters.

  4. Specify a New API Version Name. This can be any string of ASCII characters.

  5. Optional. If you have a private or public portal for the API, you can upgrade the portal as well.

To Request Your Platform Upgrade

The upgrade is triggered automatically at the time you schedule in the self-service portal. Access this portal from the green banner in the Anypoint Platform login. The estimated upgrade time is 15 minutes for each 50 APIs.

During this stage, API design projects and API portals are moved into their appropriate new home. API specifications and API portals are stored and versioned in Anypoint Exchange, and new projects are created for them in Anypoint Design Center. SOAP APIs or APIs without specifications are moved to Exchange only and not added to Design Center.

After this process completes, the user who scheduled the upgrade receives an email confirming a successful upgrade. In case MuleSoft encounters issues, MuleSoft automatically rolls back an upgraded account to its previous experience. You can contact MuleSoft Customer Support with any questions on resolving these errors.

Post-Upgrade: To Classify APIs into Environments

After the upgrade, all APIs are listed in an environment called the Unclassified environment. From here, you can classify APIs into your appropriate environments. Even though API Manager supports tracking APIs by both organization and environment credentials, MuleSoft recommends using environment credentials as the permissions associated to them are more restrictive. But, you need to restart Mule Runtime after changing credentials, which can cause downtime.

The names of APIs you see in the Unclassified environment reflect the original API names you had prior to grouping your APIs. This is so that you can easily determine the environment for each API.
  1. Update the server where the API or API proxy is running. (Optional: only needed if you would like to use environment credentials for API tracking. You can still continue to use organization credentials that don’t require any changes on Mule runtime configuration.)

  2. Classify the API into the suggested environment.

Using credentials from one environment does not allow:

  • Tracking APIs from different environment

  • Tracking APIs from different organizations

For more information see To Classify APIs.

FAQ on Upgrades

Is there any downtime?

There is no downtime during the API grouping or the automated migration. We do, however, advise not to use API Manager during the upgrade process to prevent any data inconsistency. After the upgrade, classification of APIs into environments may cause downtime due to proxy restart.

How do I cancel my upgrade?

After you accepted the calendar invitation sent to you, open the email with subject "Your booking confirmation". Click "Cancel booking" and click "Cancel this booking" in the window that opens. Once you cancel, a confirmation email will be sent. For help, e-mail crowd@mulesoft.com. When you are ready to select a new time, log back into the platform to schedule the upgrade.

How can I test the upgrade before scheduling the upgrade for my Anypoint org?

Our general recommendation is to create a trial account. This will be created as an upgraded account. Therefore, request your Customer Success Manager to convert the account to pre-upgrade with self-service upgrade scheduling for the trial account. Create dummy APIs for your testing purposes. Schedule an upgrade for the trial account using the instructions you will see on login after the trial account is converted to "pre-Crowd".

Who should I contact for questions during the process?

Open a case in the support portal.

After the upgrade, how does API usability change?

After the upgrade is complete, APIs stored in API Manager before the upgrade will have been moved as follows:

Before the Upgrade Afterwards Description

API Manager:
API Specifications

Design Center:
API Specifications

All RAML files from API Manager automatically appear as an API Specification Project within Design Center. This project is visible to everyone within a business group.

API Manager:
API Portals

Anypoint Exchange:
API Portals

API Portals are available for access through Anypoint Exchange, instead of API Manager.

API Manager:
API Proxies

API Manager:
API Proxies

APIs stored in the API Manager move to the Unclassified Environment. API providers need to classify each API to the appropriate environment.

Can I bulk classify APIs into a specific environment?

No.

What is the "Unclassified" Environment?

After the migration completes, all APIs appear in the Unclassified Environment. All APIs that haven’t been classified into a real environment can be managed from here. This environment has the same user interface and permissions model as the pre-upgrade API Manager.

All APIs in the Unclassified environment can be classified into a real environment by following the process described in this document. If API grouping information was provided before the migration, that information is used as the API name and version of the API being classified in the target environment.

Is there a rollback available?

Yes. If you have problems with the new experience of Anypoint Platform, you can open a support ticket from MuleSoft Support and we will execute a rollback. Note: Rollback is only available if no APIs were classified. We recommend to request rollback within 24-48 hours. New changes after the upgrade will not be carried over with a rollback.

New and Changed Features

  • All APIs created using pre-upgrade version of API Manager appear in the Unclassified Environment after the upgrade

  • APIs in the Unclassified environment can be classified into the corresponding environment following this process.

    • Configure Autodiscovery element for new APIs after the upgrade in the following way (retrieve all values from the API and the UI):

    • name=”groupId:{{groupId}}:assetId:{{assetId}}”

    • version=”{{version}}:{{instanceId}}”

  • API Manager API (v2.x) is available to leverage all new API Manager capabilities.

  • User permissions model has changed to be action-based at the environment level, which is aligned to the rest of the management center. After the upgrade, administrators should set environment-level permissions for all users. Default environment-level admin roles are available. The permission model in the Unclassified environment works in the same way as API Manager permission model worked before the upgrade. Assigned permissions for APIs in the Unclassified environment also remain untouched during the upgrade process.

API Designer

  • To make changes to a RAML of a running or published API, users need to republish any specifications in Exchange that have versions.

  • Design Center projects do not have tags like old API Manager projects.

  • API sync from Studio 6 and 7 only supports pull only.

API Portals in Exchange

  • External links from the navigation panel are grouped under the Helpful links section in Exchange.

  • Invisible pages are deprecated and replaced with draft functionality of Exchange. All invisible pages become draft after the upgrade is complete.

  • Branding at the API portal level is deprecated and replaced with global branding control. This means that all API portal pages inherit global styles.

  • To update an API specification available in Exchange or used by an API proxy in API Manager, users need to publish a new version of API specification to Exchange using API designer.

  • Internal API consumers can see all API endpoints and versions through an API portal they have access to. Existing API Manager controls permissions per API version.

  • Onboarding of external users of API Public Portals onboarding has been simplified and there’s no need to invite external users for them to be able to consume APIs and request API keys.

  • When APIs are migrated to Exchange, Exchange calls REST Connect to generate connectors for Mule 4 and Mule 3. Because REST Connect only supports RAML v1.0, owners for API specifications based on RAML v0.8 receive an email notification with a message that the connector creation has failed. They can still use Design Center to open and edit these API specifications, but these specifications cannot be used as a connector in Design Center, Studio 6, and Studio 7.

APIs in API Manager - Post-Upgrade

  • APIs utilizing an autodiscovery element now use API Manager instead.

  • API promotion to environments is a new feature that you can introduce as a step in your CI/CD pipeline.

  • Because the November release upgrade moves all portals and RAMLs, the old API cannot be used to modify, create, or delete them after the upgrade.

  • The pre-upgrade API Manager API can be used with APIs in the Unclassified environment with some restrictions (see below). There are also new environment-aware APIs, which also support the Unclassified environment, that you may start using (see the new API Manager API portal and the Proxies xAPI portal).

    • The following resources for managing RAMLs return 400. Use Design Center APIs instead.

      
                      
                   
      1
      2
      
      /organizations/{organizationId}/apis/{apiId}/versions/{apiVersionId}/addRootRaml
      /organizations/{organizationId}/apis/{apiId}/versions/{apiVersionId}/files/*
    • The following resources for managing portals (including permission setting) return 400. Use Exchange APIs instead.

      
                      
                   
      1
      2
      3
      4
      
      /organizations/{organizationId}/apis/{apiId}/portals
      /organizations/{organizationId}/apis/{apiId}/versions/{apiVersionId}/portal/*
      /organizations/{organizationId}/portals/*
      organizations/{organizationId}/public/*
    • API creation needs to be done in Exchange first, thus creation of an API from API Manager API returns a 400 response.

  • APIs exported before the upgrade cannot be imported after upgrade.

CI/CD Changes to Make

The Anypoint Platform APIs section of this doc has links to the API documentation so you can update your pipeline per any of the below criteria:

  • If you call API Manager APIs to apply API management or policies, review the API Manager API and refactor your pipeline as needed.

  • If publishing to Exchange, review the new Exchange Maven Facade API and refactor as needed.

  • If you apply Policies, SLAs, etc., review API Manager API and refactor as needed.

Anypoint Platform APIs (November 2017 Release)

The following is a list of platform APIs that orchestrate the API deployment and management CI/CD automation. See the MuleSoft Developer Portal to find all the available Anypoint Platform APIs.

Component API Portal Before 17/Nov/2017 Exchange Portal 17/Nov/2017 and Later

All Platform Portals

Anypoint Platform Developer Portal

MuleSoft Developer Portal

Access Management

Access Management API

Access Management API

CloudHub

CloudHub API

CloudHub API

The CloudHub Public API enables you to access application management services for applications deployed to CloudHub.

API Platform / API Manager

API Platform API

API Manager API

The API Manager API enables you to manage an API by applying policies, setting SLAs, configuring alerts for your API instances, and promoting API instances.

API Platform v2

The API Platform API exposes the management capabilities of the Anypoint Platform for APIs, enabling them to be used by external sites.

Anypoint Runtime Manager (ARM)

ARM APIs

ARM Rest Services

Exchange

Anypoint Exchange - 1.6.1

Exchange Experience API

This API basically focuses on assets and portals. It allows doing a lot of operations on different organizations according to the permissions that each user has in Anypoint.

Exchange Graph Service (API Reference) - v1

The Exchange Graph API lets you query Exchange assets filtering by multiple criteria and returning only the information you need. To try the Graph API, Click the Docs button in the top-right corner.

Exchange Maven Facade (Maven Facade) - v1

The Exchange Maven Facade API lets you interact with Exchange using the Maven client to publish and consume Exchange assets as Maven dependencies.

You can use the Exchange Maven Facade API for Mule applications, templates, examples, connectors or policies. RAML API specifications are not supported, use the Design Center xAPI to publish those assets.

Proxies

N/A

The Proxies XAPI allows you to download or deploy proxies into Runtime Manager. Proxies API v1

CI/CD Architecture

The following diagram gives an overview of the CI/CD (continuous integration and delivery) process.

CI/CD architecture diagram

When working with large teams and multiple applications, the manual process for testing and deployment is challenging and teams should consider using a Continuous Integration and Deployment server like Jenkins.

About Continuous Integration

The need for continuous integration (CI) for a project is very important. By using Maven as your build tool, you can create a build that gets triggered on every project change, and run all its unit and functional tests automatically.

The advantages of continuous integration are:

  • Early notification of issues in the software development lifecycle.

  • Ensures code gets fully tested before release.

  • Successfully tested branches ensure better success when merging to the master branch.

A continuous integration system:

  • Listens for new commits to a project’s source code management system. The CI watches many branches for new commits. You can use either polling to find new commits, or the management system can trigger events that inform your program of commits.

  • Pulls the newest branch into a centralized server.

  • Creates build jobs on a centralized server.

  • Runs configurable unit and integration tests on the code base to compile, test, package, and deploy the project in a sandbox to ensure the project works correctly.

  • Stores artifacts in a repository.

  • Displays the results of each build.

  • Deploys passing builds to production.

To Prepare Applications for a CI/CD Server

  1. Use a source code repository, such as GitHub or BitBucket.

  2. Add the following configurations to each Maven pom.xml of each application:

    • Mule Maven plugin for CloudHub, ARM, and Standalone deployment.

    • Mule Maven plugin for MUnit.

  3. If using a Jenkins pipeline, add the Jenkins files to the Mule project.

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.

+