Achieving Better, Flexible, and Inclusive Collaboration by Integrating MuleSoft and Slack

Introduction

More connectivity, more integration, and more communication are some of the most important factors for companies to remain competitive in these days where the market across all industries is quite tight. Invariably, these are reflected on how enterprises invest in IT and of particular relevance, how they integrate their systems and streamline communication and collaboration.

When it comes to the “combo” — integration and collaboration, MuleSoft and Slack reign supreme. The focus of this article is an approach to the practical implementation of integration between them, addressing common needs of platform monitoring and maintenance, performed by Anypoint Platform administrators. Throughout this very technical post, we will implement a solution that allows MuleSoft operations teams to perform common monitoring tasks in Anypoint Platform via Slack (commands), implemented in Java Spring Boot, leveraging Anypoint Platform APIs as a backbone.

The complete source-code of this solution is available in Github.

High-Level Solution

First things first, let’s outline what are the features that this solution will provide to our platform administrators:

• LIST Business Groups (under main organisation)
• LIST Environments by specified business group
• LIST Cloudhub Applications by specified business group and environment
• LIST APIs by specified business group and environment
• LIST Monitoring Metrics (CPU, Memory, Performance, Requests/Failures) during the last X number of days by specified business group and environment
• EXPORT Monitoring Metrics (CPU, Memory, Performance, Requests/Failures) during the last X number of days by specified business group and environment. The result is a downloadable Excel file containing the required metrics

Obviously this is a very shortened list, adapted to the specific context of this article and demonstration of the technique, but the list of features could go on and on…

Moreover, these features will be implemented and made available via a Spring Boot REST API that works as the Slack Command, leveraging Anypoint Platform APIs to surface data.

This API (Slack Command) will accept a certain number of parameters provided by the user, where input resembles a SQL query-like structure, for example to list Cloudhub Applications within a business group and Environment, a Slack Command /anypoint would have the following user input parameters:

/anypoint LIST CloudhubApplications WHERE BusinessGroup=deloitte-au AND Environment=prod

As those features tend to grow over time, it’s crucial that a well maintained documentation is freely available and also that the Slack Command itself allows the users to ask for help by either not passing any input parameters or simply asking for help as in:

/anypoint HELP

Which should result in a list of all the available features and valid input parameters.

The below diagram illustrates how the solution works from an end-to-end perspective:

Slack Front-end Configuration & Implementation

Yes, that’s right! Even though all the heavy lifting will be later on be done by the Spring Boot API that consumes Anypoint Platform APIs, a good chunk of the solution requires implementation in Slack.

In this solution, Slack collaborates by operating as the frontend, capturing user input and interactively displaying results (using Slack Block Kit UI Framework). As such, the implementation in Slack is divided in two parts:

• Registering and configuring a new application as a Slack Command
  https://api.slack.com/interactivity/slash-command
• Building Block Kit UI to allow interactivity with Slack Command for each of the different features
  https://api.slack.com/block-kit/building

Slack Command

This can be done by browsing Slack Apps and adding a new application Slash Commands. After adding this application to Slack and registering and configuring our Slack Command, when viewing configuration, a screen similar to the screenshot below will be seen:

With that configuration in place, we have a Slack Command that responds to interactions by sending an HTTP POST to the defined URL (must be HTTPS), containing an endpoint /api/v1/commands/anypoint.

Slack Block Kit UI

The next (and most fun) part of the work in Slack is designing the UI that corresponds to each of the responses. As mentioned above, that type of interactivity in Slack is implemented by leveraging the Slack Block Kit UI Framework, which in practice is a set of Blocks (visual components represented in JSON) that can be stacked and arranged to create app layouts. Thankfully, the awesome team at Slack have created a tool Block Kit Builder, where developers can declare all the block elements visually, using drag-and-drop. The below screenshots illustrate how some of our Slack Command responses look like at design time in Block Kit Builder:

Processing Request Response

Monitoring File Download Response

Slack Command (Spring Boot API) Implementation

Having finished working out the bits and pieces of the front-end part, let’s start bringing our Slack Command to life by implementing a Spring boot REST API that interacts with Anypoint Platform behind the scenes.

The Spring Boot application will export a single REST endpoint /api/v1/commands/anypoint that will parse the received parameters in the command and orchestrate calls to Anypoint Platform API, finally producing a response according to what the user provided. The diagram below highlights how the different classes that comprise this application will hang together:

From the simplest packages and classes to the most complex and specialised ones, we have the following:

• Anypoint Models
  Responsible for representing each of the JSON resources in Anypoint Platform (e.g. AnypointApi, CloudhubApplication)
• Anypoint Mappers
  Responsible for transforming JSON to Java classes and vice-versa as required (e.g. JsonToAnypointAPI, CloudhubApplicationToJson)
• Anypoint Connector
  Responsible for exposing an object-oriented abstraction to communicating with Anypoint Platform APIs
• Cache Services
  Responsible for maintaining a cached entries of Java representation of the resources in Anypoint Platform (e.g. Cached Business Groups, Cached Environments)
• Slack Commands
  Responsible for implementing Slack Command logic, coordinating calls to either the Cache Services or Anypoint Connector as required
• Slack Block Builders
  Responsible for building and generating Slack Blocks according to the response of each of the invoked commands
• API Controllers
  Responsible for accepting requests from Slack, acting as an entry point interface for Slack Commands (REST API)

Next we go over fine-grained details regarding the more specialised and concrete classes.

API Controllers

There are 2 entry points for this API as API Controllers, where one is responsible for acting as a Slash Command, parsing and processing requests and the other one is responsible for managing download of files.

CommandsController
This Controller class exposes a method annotated with a @PostMapping with a path “/anypoint” and consuming MIME type “application/x-www-form-urlencoded”.

When a user uses the command, Slack will send an HTTP POST request to the endpoint configured, encoded as a URL encoded form containing containing the following fields:

Where of particular relevance to the Controller class and how it asynchronously responds to the command, the response_url field. This field is later on used by the API as a callback URL to where a response payload will be sent when processing the request is complete.

Anypoint Connector

The most central piece of the application, this class is responsible for doing all the heavy lifting, routing, and performing underlying HTTP calls to Anypoint Platform APIs (including login and retrieval of a bearer token), based on input parameters and application configuration, where user credentials and URLs are configured in configuration properties file as below:

This class will have a large set of methods to perform each of the functions required to process requests:

AnypointConnector class will be leveraged directly by each of the implementation of Slack Commands to process the required action using Anypoint Platform APIs as detailed next.

Slack Commands

These highly specialised classes are responsible for coordinating calls to either the Cache Services or Anypoint Connector as required, passing in received parameters and interpreting returned results, lastly generating a Block Kit response using the corresponding Slack Block Builder class. Based on a pattern of creating very intuitive names, this package is comprised by the following classes:

• AnypointSlackCommand
• AnypointSlackCommandParameters
• ApisCommand
• BusinessGroupsCommand
• CloudhubApplicationsCommand
• CommandHelpCommand
• EnvironmentsCommand
• MonitoringCommand

Slack Block Builders

These are nothing but utility classes, responsible for parsing templates (Slack Block Kit UI JSON contents) and generating JSON responses based on data objects (models). Each of the Slack Block Builder classes have 1 or 2 associated template files (1 x header and 1 x detail), maintained as application resources, living with resources folder as per mapping below:

• CommandHelpBlockBuilder
  - /resources/CommandHelp.slack
• RequestAcceptedBlockBuilder
  - /resources/RequestAccepted.slack
• MonitoringFileDownloadBlockBuilder
  - /resources/MonitoringFileDownload.slack
• ApiManagerApisBlockBuilder
  - /resources/ApiManagerApis.slack (HEADER)
  - /resources/ApiManagerApisItem.slack (DETAIL)
• BusinessGroupsBlockBuilder
  - /resources/BusinessGroups.slack (HEADER)
  - /resources/BusinessGroupsItem.slack (DETAIL)
• CloudhubApplicationsBlockBuilder
  - /resources/CloudhubApplications.slack (HEADER)
  - /resources/CloudhubApplicationsItem.slack (DETAIL)
• EnvironmentsBlockBuilder
  - /resources/Environments.slack (HEADER)
  - /resources/EnvironmentsItem.slack (DETAIL)
• MonitoringBlockBuilder
  - /resources/Monitoring.slack (HEADER)
  - /resources/MonitoringCpuItem.slack (DETAIL)
  - /resources/MonitoringMemoryItem.slack (DETAIL)
  - /resources/MonitoringPerformanceItem.slack (DETAIL)
  - /resources/MonitoringRequestsItem.slack (DETAIL)

Collaborating with Slack and MuleSoft

When configured and deployed the solution can be brought together and manually tested in the old-fashioned way by calling the Slack Command. Taking our Mule for a first practical ride, let’s suppose that as an administrator, one wants to list all the available business groups within an organisation and calls the Slack Command:

The corresponding result in would look like (blackened and anonymised for the most obvious reasons):

For a more interesting and complex one, suppose that very administrator wants to view MEMORY utilisation in Cloudhub Applications during the last 120 days. In this case, the command to be run would be:

And the response received would be similar to:

Additional Features

Virtually the only limitation here would be related to any data that is not readily available via an Anypoint Platform API, which is a bit unlikely, but in the very exceptional case of some unavailability, the outstanding enginerring team at MuleSoft offers the IdeaExchange Portal where platform users can share and vote for ideas, which could be added to next feature release.

Knowledge of MuleSoft Anypoint Platform APIs and Java Spring Boot for programming is a must for improving and adding more and more features to this little app. In either case, the source-code is very easy to follow and modify to one’s specific needs and again, is available from Github.

Conclusion

In this post, we have demonstrated how enterprises can leverage best-of-breed solutions using MuleSoft and Slack to innovate and unleash a set of new ways to streamline how platform administrators can communicate and collaborate in a common, democratic and unified mode, using tools and techniques readily available for consumption and use.

Having come this far you might be wondering where to go next and what other features would be highly regarded. Well, I may suggest at least a few them, which would not only be quite useful, but also fun to implement:

• Listing and allowing approval of new API contracts (based on SLA, etc.)
• Fetching and displaying status of Anypoint Platform components
• Retrieving release notes of scheduled runtime upgrades
• Searching for assets in Anypoint Exchange

Now it’s up to you and others in the integration community to flash out new ideas and add more and more functionality to this.

Enjoy!

The Author

Eduardo Ponzoni is an experienced integration developer, architect, and manager with 19+ years of experience. Well versed public speaker and author of dozens of articles on all things systems and data integration. Leading from the front and by example, Eduardo is a MuleSoft Ambassador, holds several certifications and loves sales and delivery. He has led multi-disciplinary teams in digital transformation programs with MuleSoft, Kafka, Azure & Boomi. Currently at Deloitte AU as Director of IT & Cloud Engineering with a focus on Integration, he is responsible for growing the integration business across Australia, from strategy, roadmap, vision, sales/pre-sales to hands-on execution & delivery as a people leader and technology specialist.