CAI - Convertional AI - Bot Building Best Practice

[former_member327092]

Dear Community,

We are in the exploration phase of the building some chat bots using SAP CAI. Would like to understand some of the best practices while implementing. If you could provide some insights on this that will be great. Sorry for the long list of questions -

1) If we have 3 different business functionalities that are required to be built as a bot - Do we build 3 bots with their own intents and skills or we will build one common bot with multiple intents and skills within the same bot. I am assuming its the later as users need not trigger multiple bots separately and also the connectivity channels can be done only to one bot instead of 3. Please share your thoughts.

2) Webhooks vs Direct API Consumption - For simple read only and status bots Direct API consumption seems to be very simple and we were able to successfully connect our on-prem servers and get responses back. I understand webhooks was initially the only option with connecting to api's. If we are able to use Direct API, is there any scenarios where webhooks will be really helpful over the direct api?

3) How will the project lifecycle be handled in the bot development? We usually have a dev, qa and prod sub accounts in SCP. Do we need to enable the SAP CAI in all the sub accounts or only in dev we will create the bot and then we need to use versioning concepts for qa and prod. If we use versioning concept how do we connect the API's to the respective backend servers as the destinations are created in different sub accounts?

Thanks.

[JonasB · Accepted solution]

Hi N K,

1) Yes, typically you should have one bot with multiple intents and skills.

2) Webhooks are ideal when you would like to implement parts of your bot logic in your own service to have more flexibility, e.g. to apply more advanced transformations to the data fetched from an external system. For simple scenarios where you would like to just fetch information from a system, API service configurations should be sufficient and are the recommended approach.

3) Currently you're basically limited to use one subaccount only, as there is no transport of a bot possible between subaccounts. There are plans to provide functionality allowing transport between the subaccounts for the use case you describe, but unfortunately there is no clear timeline yet.

Regards
Jonas

[former_member327092 · Accepted solution]

Thanks jonas.brand for the clarification.

So, if we have to go live with 3 environments (D, Q and P) what's the recommended approach from SAP for building and deploying the bots in these environments. I am ignoring the N and N+1 landscape for simplicity 🙂

1) Do we have to create 3 different versions of bot in CAI?

2) How will we manage the connectivity to the backend on-prem systems? Dev and QA are in the same cloud connector so we can probably create multiple destinations in the dev sub account and connect to the respective cloud connections. Production would be a problem as it will be in different cloud connector and also creating a production destination in development sub account causes unnecessary noise in the organization. How to deal with this situation? How to dynamically have the bot pick the right destinations?

Thanks again for your response.

[JonasB · Accepted solution]

Hi N K,

current recommendation would be to have one bot with three environments for development, qa and production and to enable system aliases for your bot, which will allow you to select different destinations for each of the environments. In the actual API service configurations or webhooks you will just select the system alias and best on which environment is used, the corresponding destination will be used. When using channels, you just create on channel per environment and assign the environment accordingly. When using the /dialog API directly you should make sure you use the environment request token (and not version request tokens) which makes sure that the right destinations can be selected during runtime based on the environment.

Technically you can connect multiple SAP Cloud Connectors to one subaccount by using different location IDs. I agree this is not ideal, but currently unfortunately the only option.

Regards
Jonas