Introduction

Part of our responsibility is giving technical presentations to students about various technologies. We also have a lab at the University where we give the presentations and spend most of our time and where other students can come and work on their projects.

Up until in September, we used Facebook for almost all of our communication (I know, my feelings as well).

So we had a Facebook group for our communication inside the team (which was a total mess since it was a single chat channel) and people would ask us questions on our Facebook page.

Introducing Slack

In September, I thought it was high time we changed the way of communicating, so each of us came up with solutions.

People inside the team proposed Skype or keeping Facebook, while I had the idea to try Slack for a few weeks and decide if we liked it (the question was wether the team was going to like it, I was sold on it).

So we used Slack for a week or so, until (most of) of the team was (almost) satisfied with it.

A few months passed by and we had grown into using Slack for all of our internal communication, for programming, team management or totally random stuff.

Our custom requirements

Then, we decided we needed to advertise the fact that people can come in our lab and work on their projects.

So we needed a way to communicate with people not using Slack (since they were not part of our team but random students), and inviting them on the team was not an option (for the obvious reason – we didn’t want random people in our Slack team).

We also considered solutions like this one that add a button automating Slack invites, but people needed to ask quick questions answered within minutes – so creating and confirming a Slack account was, again, not an option.

Creating the custom integration

So we decided to create our custom Slack integration.
Since I am familiar in developing web applications using the .NET Framework, it seemed only natural to create this integration using Asp.Net WebApi as web server, SignalR for real-time communication and an Azure SQL database as message store.

Posting messages to a Slack channel from a public web page

As I said earlier, posting messages to a channel from the outside was done using Incoming Webhooks.
I set up an incoming webhook for a specific channel and received an URL that I used to post the messages to and was passed to the SlackClient constructor.

Basically, what SlackClient does is a POST request to the URL provided by the Incoming Webhook with the message as payload (the method that actually sends the message to Slack is PostMessage from SlackClient).

This is the actual controller method that gets executed from the UI when somebody sends a message.

This method simply makes a POST request with the message to the URI received from Slack.

Posting messages from Slack to the public web page

When setting up a slash command, you are asked to provide a URL where Slack will create a POST request with the content of the command (including the message).

Among other things to consider (you should always check the command token to make sure the command you received is from your team), your method (in my case the PostMessageToWeb method from the SlackController) receives the command and has to publish it to the public web page and back to the Slack channel.

This method receives the command request from Slack, verifies that it actually came from your team, broadcasts the message to all connected clients on the web page, sends the message back to the Slack channel and saves the message on the Azure SQL database.

Testing and publishing the app

You can test the part of the app that publishes messages from the web page to Slack locally. But if you want to test the part that sends messages from Slack, you need to have a publicly accessible URL that Slack needs to send the commands to.

So I published it as an Azure WebApp and gave Slack the URL to send commands: /api/Slack/PostMessageToWeb.

If you don’t need it, you can exclude the message store and the SQL Database, but you must remove the dependencies for SlackMessageStore and for SlackDbContext, and the not register SlackDbContext with the builder.

Next steps

create a UI for the public web page

create support for automatic responses

add support for attachments in messages

Conclusion

The whole idea behind this integration was to create a simple way for people outside our team to communicate in real-time.
The solution was a WebApi solution with SignalR for real-time communication and an Azure SQL for the message store.