Webhook process

Hello. I’m connecting my rasa bot with rocketchat livechat. Currently it listenes to all messages, even if it shouldn’t proceed with the current user. So the question is, how can I process webhooks that I get to localhost:5005/webhooks/rocketchat/webhook, e.g. I want not to pass webhook to bot if it contains incorrect field.

1 Like

Hey @gsp0din, awesome that you got it set up! The way we recommend to use the rocketchat connector is to set it up so that your bot only responds when it is tagged. The instructions are here: RocketChat specifically steps 4 and 5. Does that achieve what you want it to?

First time we set it up was with this integrations, which worked fine until we created custom action that does something outside rocketchat, send email. And we found out that actually bot listens to all messages in all private groups, for example if I’m talking with someone in direct or if livechat visitor talks with real agent and not bot. For us the main task was to create a livechat in our website. And rocketchat admin suggested to use another webhooks which is in the other panel called livechat. It listens to all visitor’s messages, which is already better, but still if user talks with the agent and not with the bot, bot will listen to that too. And to solve this issue I had to change rasa package, specifically rocketchat.py file where you create input and output channels for rocketchat, I just processed webhooks myself, which isn’t great because I had to change the package. So my question is, can I somehow affect how webhooks are processed without changing package files?

No, you can’t change how the webhooks process messages without changing the files, however, it’s completely normal to have an output channel that you maintain yourself – lots of people create their own files for their custom channels.

I understand, currently I just change initial files, however maybe you can suggest a way to create my own class or something like that?

You shouldn’t have to change anything other than the rocketchat.py file. What i’d recommend doing is copying the unchanged file into another one, say myrocketchat.py, and changing the class name functions of rocketchat to myrocketchat in the file. Then you are able to have both versions so that you can test the current functionality against yours.

The instructions for using your version as your I/O channel can be found here:

But if I update my package, then I would have to copy myrocketchat.py file again, right? I mean there should be no way to automate this process, at least because you can change your interface.

I mean, that’s what github is good for, you can just merge any changes into yours, and you can see exactly what has changed so you can decide if you need to update anything in your custom code…

But no, there’s no way to automate updated – once you’ve gone and personalized things, you’re in charge of maintaining them. If you think about it, we’re doing the same thing too. If rocketchat changes their API, we have to update the code we’ve written to deal with whatever changes they make. If you want to add customization on to our code, then you’ll have to do the same.

I’m not really sure, but I think I use pip to update packages and not github. Maybe pip uses github, then I get it

Yeah, you would have to manually check what has changed, probably. Eg here you can see the commit history for the file, if nothing has changed recently then you’re probably fine. In any case you’d really only have to check if/when a bug pops up.

This may be a tad off topic, but how is one to set slots in button payloads in rocketchat without using the trigger word?

As you can see in this snapshot, the payload does not include the trigger word and is thus never sent to the rasa api:

image

  • putting the trigger word in front of the payload object causes unexpected results
  • putting the trigger word on a new line in the same message works but is ugly:

@mkoser That’s a very good point. As of now I’m not sure if there is an elegant solution to this, as stuff that starts with / is parsed by a completely different interpreter :thinking: I’m actually surprised the newline worked.

Can you create a github issue for that? Maybe other people will have good input about how to get around this.