Take blip give you guidelines on how to build a router architecture with our best practices

Overview

This article’s main goal is to give you some guidelines on how to build your router architecture using Take’s best practices. Following this rules you’ll improve your bot router maintainability making it easier to any other developer act on it if necessary.

Architecture

Before starting you should take a moment look to your project and define what skills it will have. Just like we build uncoupled objects when programming, you want to create independent sub bots. Imagine we have to create a Pet Shop bot, the “Such Wow Pet Shop”, this bot will have some skills: Services, where we gonna offer our bath and trim services for instance, Products, where we gonna showcase what we sell in the store and Help Desk where our customers can talk to someone.

  • Products
  • Help Desk

Main Bot

The Main bot is the first entry from which your bot can interact with the user, so this bot will not return to the start after redirecting to another bot, instead it will continue from the next block which contains an user input, so plan accordingly.

One Feature, One Skill

Now that the main bot is your controller, for every feature (skill) your bot may have we will create one bot to deal with that. So in the above example we planned 5 skills, Bath and Trim, Hotel, Products, Help Desk and Scheduling. Each one of those skills will become one new bot where we gonna deal only with what this skill should do.

✔ Always begin and finish in the start block

The start block of your bot is key so when not in the main bot and you’re sending the flow back to the main or to another bot from your skill, makes sure to send the flow of the current bot back to the start block of this particular skill, so next time another bot send the flow to this bot it will start from the start block.

⚠ Error handling is a Skill

Handling errors in your bot is a skill, although some specific errors you want to deal inside each skill, generic ones can be sent to a common bot to deal with it. You can use a callback to send it back to the flow you were.

Redirect Messages

As previously stated, every redirect will have to be done using a message, that message should be a JSON, so you can customize it as needed but as a standard we use those fields:

  • "custom": {"field":"value"} if you need to add more information use this field to do this.
  • "callback": {"serviceName":"name","flow":"someId","parameters":{}} use this if you need to send the flow back to another service after executing what you want.

Flow must go on

Bear in mind that when you redirect from one bot to another the flow in the origin bot will keep running until it gets to wait for another user input, that may lead to some issues and/or users stuck in the middle of your flow if not treated correctly.

Artificial intelligence

First of all, we must define a pattern which simplifies the consumption and maintenance of artificial intelligence (AI) in router architecture. You’ll probably have one or more AI model and will consume these AI models in all skills. And we must know where we should train and publish these AI models.

Request

Headers:

Response

Body:

Use Cases

Regional Branches

If you gonna have different initial contacts with the same content or services like, for instance, a bot connected to whatsapp but with different numbers for each regional branch the company has, lets say Belo Horizonte and São Paulo, you just need to register all the services in all routers created and in the main bot you execute a Script like this:

Help Desk

This is quite common actually, your bot will need to send the user to a help desk if it is not able to find a solution to the user’s problem itself. For that, create a bot to handle only the help desk, so it will have any kind of checking for time frames, online agents, anything related to make the help desk service available or not.

Contact’s information

When the user is sent to help desk, the contact that is fetched by the Desk is the tunnel’s one, not the router’s! It means that changes on contact won’t reflect on desk.

Testing

As you are probably aware of, the blip’s debug mode does not works with routers, so if you need debug information you will have to test the skill individually.

Conclusion

If you follow our guidelines your routers will be easier to maintain, the communication between them will be better and you’ll be able to perform more complex tasks sharing information and actions through skills.

Tech Lead @ Take | Bachelor in Computer Science @ UESC