Considerations for Simplifying Accelerator Assets

MuleSoft Accelerators follow an API-led approach to connectivity, which separates app, process, and system integration layers while enabling a high level of reusability, particularly with System APIs. The low maintenance costs and ability to enable future growth make this process highly recommended. However, if you want a less complex approach, follow this guidance to simplify your integrations and architecture.

Simplify Accelerator Assets

Keeping the assets and corresponding solutions as simple as possible drives the design and implementation of use cases supported by the MuleSoft Accelerators, as well as providing solid, functional, and maintainable architectures for customers to build upon.

The following key principles demonstrate the philosophy behind the solution design:

Follows the API-led connectivity approach but creates APIs only where necessary to support clean integration with external apps and systems.
Keeps exception handling clean and simple, allowing for straightforward extension and customization.
Avoids using heavy logging, monitoring, or exception-handling frameworks.
Leverages a reusable canonical data model within the business process layer to simplify communication between layers.
Uses messaging only where necessary to support high-volume deployments.
Uses inline subflows instead of top-level flows where possible.

The assets developed for the MuleSoft Accelerators are flexible and extensible, supporting existing use cases and other use cases that customers need to support their business. Some APIs include additional endpoints, especially System APIs shared across multiple use cases. Not all customer deployments require the additional endpoints. The reference architectures for most solutions support long-term growth and evolution, which can result in additional apps and interactions that are not always required for smaller deployments.

To reduce the number of flows in accelerator apps, apply the guidance in the following sections.

Remove Unused APIkit Handlers

Remove scaffolded flows from the main router flow file in APIkit, which is usually the *-api.xml file.
Leave the API specification unchanged instead of rescaffolding, because you always edit the file manually to remove the scaffolded flows.
Avoid circumventing the APIkit router with a plain choice router, because that makes the router less discoverable and increases maintenance costs.
Remove the flow for the APIkit console.

Remove API Health Checks

The get:/ping endpoint periodically monitors the health status of deployed APIs. If you don’t need to monitor, remove the handlers for these endpoints from the main APIkit flow file. If you keep the endpoints, remove the checks for downstream dependencies to reduce messages and throughput.

Generalize Event Sources

Instead of creating monolithic flows that listen to generic events, combine event sources into more granular events. For example, general events exist for publishing and consuming updates to Parties, such as Individual and Household, and to Party Roles, such as Customer and Supplier. By combining the update queues, you bind them to both Exchanges and a single handler consumes them. You receive the same number of messages but with fewer flow event sources.

Take the same approach for VMQueue subscribers, SFTP listeners, and other event sources.

Reduce the Number of APIs

Backend systems like Salesforce have a modern API and limited mapping between a canonical model and the backend model. To reduce the number of message flows, consider making calls directly to the target system from the Process layer instead of through a dedicated System API.

The use cases for Experience APIs provide data transformation, authentication mediation, and service filtering for external consumers. If API Manager governs the target APIs, you don’t need an Experience API for internal systems aligned to the same data, authentication, and services as the Process or System APIs.

When providing similar functionality to external apps via Experience APIs, find opportunities to provide a single Experience API to support multiple channels, rather than one Experience API per channel. For example, combine multiple Salesforce Experience APIs to reduce the number of message flows and apps.

Provide shared functionality via Mule libraries instead of standalone APIs, such as when an Account or Order lookup from Salesforce is required by multiple apps in the Process layer. To reduce flows and message count, implement the shared functionality in one or more subflows, package it into a Mule library, and include it with the Process APIs.

Additional Simplifications

To simplify your integrations, reduce the number of Mule messages and throughput.

Reduce Mule Messages

Receiving an event from an event source, including incoming API requests, produces Mule messages. To consume fewer messages when handling a top-level event, reduce the number of API-to-API calls, such as Experience API to Process API.

The accelerator solutions also avoid making unnecessary hops, such as an Experience API calling a System API directly when no intermediate transformation, validation, or aggregation is required. The solutions avoid introducing an intermediate Process API that acts as a passthrough hop.

To optimize the solutions further:

Make calls to backend systems directly from Process APIs that have a straightforward interface for the target system.
Remove the flows for health checks that look at downstream system health if you enable the checkDependencies flag.
Replace VMQueue or Anypoint MQ messaging if you use low volume deployments and synchronous processing.
Update endpoints to accept arrays of objects instead of single items when performing request batching.

Reduce Data Throughput

Some of the simplification steps described previously also reduce data throughput. When considering custom frameworks, such as for logging or exception handling, take data throughput into account for your deployments.