[Feature breanch] Lex chatbot integration

[gpaoloni]

Description

This PR adds the require code to support migrating our pre-survey chatbot to Amazon Lex.
The bot used here can be found in AWS console. The definition for the bot was done manually via console.

This PR adds two functions:

• captureChannelWithBot.protected.ts: This function is intended to be the last to be called when the Studio Flow is triggered by a new message arriving, and only branching logic/manipulation of attributes should take place before it. It is to expect that after this function is executed no task is sent to Flex. Instead the chat channel will be "captured" by the chatbot via channel webhook. Takes as parameters channelSid, message, fromServiceUser and studioFlowSid and it will (in order):

  • Remove from the channel the webhooks of type studio, to prevent subsequent Studio Flows executions for the messages that will take place in the channel (contact and bot).
  • Creates a new onMessageSent webhook on the channel that points to the function described in the next item.
  • Adds to the channel attributes fromServiceUser (a string representing the chat service user identifier that triggered the flow) and channelCapturedByBot (an object that containing botId, botAliasId and localeId, which are the Amazon Lex target bot identifiers, studioFlowSid which is the Studio Flow sid that should be triggered when the channel is "released" and chatbotCallbackWebhookSid the sid of the webhook created in the previous step that will be removed when the channel is "released").
  • Redirects the message that triggered the flow to the Amazon Lex bot, starting a new session, and sends the Lex responses back to the channel. This is done here the first time only, so we don't lose the triggering message.

  After all this the chat channel is "captured", meaning that it is not in a Studio Flow execution, but instead will continue to react to messages via the onMessageSent webhook described above.

• webhooks/chatbotCallback.protected.ts: A channel webhook function that will be triggered on onMessageSent events (as per above function attaching it to the "captured" channels). This webhook will act as the redirect function between the contact and the Lex bot: every new message being sent to the channel, if it's from the contact (channel attribute fromServiceUser, per above function) will be redirected to the Lex bot. The messages sent back from Lex will be sent to the chat channel in order to make them visible to the contact. Lastly, if the Lex bot identified that the dialog should be closed, the webhook will delete the Lex session, cleanup the channel attributes (removing channelCapturedByBot object and adding the Lex gathered values as memory), detach this same webhook from the channel and finally trigger a new API Studio Flow execution, using channelCapturedByBot.studioFlowSid.
  The last step, triggering the API Studio Flow execution is the way to "release" the channel. Here we'll re-take control of the chat channel, making it to move through the "rest of the flow after the pre survey". One important thing to note here is that the Studio Flow widgets will require some adjustments to pull the data from, as currently we rely a lot on trigger.message. properties, which only exist in message-triggered-executions. This being an API triggered execution, will contain most of the same information under flow.data. attributes. We can add more properties to this object as needed when the execution is triggered (last step of this webhook).

To make this two functions interact as expected, the following Studio flows changes are required:

• After any branching logic (channel based, open hours, etc), call a Run Function widget Capture_Channel_With_Bot that points to https://serverless-XXXX-production.twil.io/captureChannelWithBot with:

  • channelSid = {{flow.channel.address}}
  • studioFlowSid = {{flow.flow_sid}}
  • fromServiceUser = {{trigger.message.From}}

  At this point the channel will be captured and the pre-survey will take place.
  

• Add a REST API trigger that points to what would be "the rest of the flow" after the pre-survey resolves.
  

Examples of both can be found in Aselo Development StudioMessaging Flow. To try it out you only need to change Webchat_to_Lex widget transition when "Equal to web" to point to Capture_Channel_With_Bot widget.

Checklist

• Corresponding issue has been opened
• New tests added

Verification steps

[janorivera]

oooooooh how exciting!!!

[robert-bo-davis]

I've meant to ask this question before in other code, but does twilio serverless set its own AWS creds? Is that why we use non-standard ENV vars?

If we could just use AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_REGION there would be no reason to do any manual configuration of the client.

[robert-bo-davis]

Oh. These only come in via context, not actual ENV vars, huh? Or do they? The wording in the docs is confusing.

[gpaoloni]

I think ASELO_APP_ACCESS_KEY is just the name we gave to this AWS credentials, to emphasize the fact that they are not the credentials AWS_ACCESS_KEY_ID used by Github Actions, but a different that correspond to the "aselo app user" with very limited capabilities.

Is that your questions? Sorry if I misunderstood.

[robert-bo-davis]

There is one real question:

Are these "env" vars that are being loaded from context also available at process.env.ASELO_APP_ACCESS_KEY ?

And one statement:

If they are also available inside of the serverless function in the process.env object, and they are renamed in serverless to the ENV vars expected by aws-sdk (AWS_ACCESS_KEY_ID, and AWS_SECRET_ACCESS_KEY) then there is no reason to have any of the blocks like this:

AWS.config.update({
      credentials: {
        accessKeyId: context.ASELO_APP_ACCESS_KEY,
        secretAccessKey: context.ASELO_APP_SECRET_KEY,
      },
      region: context.AWS_REGION,
    });

aws-sdk will automatically read the env vars if they are set to the expected name.

[gpaoloni]

Ah I got it now. I'm not sure if this has changed, but the way to access the env vars in Twilio Serverless is vía the context object.

[stephenhand]

I know it's just the POC, but for the production version, could we potentially break it up into 2 completely separate studio flows managed separately in TF? Anything that breaks up the studio flow is a good thing, since it can get pretty big

[gpaoloni]

I know it's just the POC, but for the production version, could we potentially break it up into 2 completely separate studio flows managed separately in TF? Anything that breaks up the studio flow is a good thing, since it can get pretty big

@stephenhand Yes we could do that, but I don't think it makes that much sense right now since the "second half" (after the post survey) will likely not have more than 2 widgets. Managing the terraform config seems more of a burden in this case, since we'll need to pass around Studio Flow sids around, and in any case the flows are already being split per-channel, making them more linear. Maybe @janorivera can share his opinion on this one?