In this Blog, I will share with you solutions to three selected challenges, which occur when handling chat partner information inputs in SAP CAI. The upcoming challenges emerged when I was building a chatbot to record employee’s working times. In Figure 1, you can see a sample chat history of the chatbot I built.

The first challenge is how to handle free text inputs. The second challenge is how to partition and separately process chat partner information. The third challenge is about dealing with invalid chat entries.

I’m convinced that acquainting you with these hurdles might be of special interest as they are independent of my chatbot’s topic and could arise frequently when creating chatbots with SAP CAI.

It is presupposed that you have at least some basic knowledge and experience using SAP CAI.

Figure 1

1) Free Text Inputs

In SAP CAI, requested chat partner’s inputs usually consist of relevant information. These interesting data submissions have to be processed properly to transmit them successfully, and in a workable manner to e.g. their corresponding slots in connected databases. In SAP CAI, this required information and data processing is often successfully executed by verifying the conformity of entities and chat partner’s inputs.

Nevertheless, using entities to reconcile entered information is not always a functioning practice in SAP CAI. A relevant case where entities aren’t a sufficient solution is when free text inputs have to be processed independently of their content.

My chatbot is set up to record employee’s working times. Besides working duration, activity number and location, a proper description of the actual working activity is required to get captured. Therefore the chatbot requests its chat partner to describe its working activity, as in Figure 2.

Figure 2

The corresponding employee then replies with a free text input, which has to be processed to the embedded database, respectively the company-internal time recording system (Figure 3).

Figure 3

As usual, the skill which requests the activity description, and the subsequent skill, have to be connected to ensure functioning integrity of the chatbot. Due to the issue that the chat partner enters a free text, which can have any kind of structure, the subsequent skill cannot be triggered by entities or intents. Instead, SAP CAI’s memory function is a suitable way to connect both skills.

When connecting two skills in SAP CAI (skill A followed by skill B), a memory C is given the value true in the action section of skill A. In the trigger section of skill B, you specify that skill B is triggered, if memory C is present.

In my chatbot for instance this looks as follows. In the skill which asks the chat partner to explain its recorded activity (description_ask), the memory field wait_aktbeschreibung is given the value “true” (Figure 4).

Figure 4

As shown in figure 5, this memory and its given value are used in the trigger section of the next skill (location_ask) to connect both skills with each other and initiate location_ask after the chat partner has entered its answer.

Figure 5

To further store the chat partner’s free text input, nlp.source is utilized.

In location_ask, the submitted activity description is memorized via nlp.source, so that it can be further processed (Figure 6).

Figure 6

Consequently, the memorized activity description can later be for instance send via an API, as for example done in Figure 7.

Figure 7

2) Partition of Entered Information

As mentioned before, using entities to reconcile entered information is not always a functioning practice in SAP CAI. Besides handling free text inputs, another case where entities aren’t a sufficient solution is when inputs have to be partitioned and then processed separately.

In SAP CAI, inputs by the chat partner are registered as Strings. Sometimes, these inputs have to be partitioned, so that they can be processed separately. This is for instance the case when entered information consists of various data, which later also belongs to separate slots in the database.

For this purpose of input partition, I outline two methods. The first method separates entered information via matching information with database content. The second method utilizes the Handlebars template language’s String-splitting function. While the first method is definitely more elegant, it cannot be applied in all cases. Due to potential imperfections of SAP CAI’s interaction between Handlebars template language and JSON value format, the second method though has some practical design drawbacks.

2.1) Partition via Information-Matching

A common application in SAP CAI is that buttons are used, which were generated by database content. If the chat partner chooses an explicit button, the information included in this button might have to be assimilated and processed separately – for example to generate a new database entry.

The several buttons, amongst which the chat partner can select, thereby exhibit the exact same structure of information, as the database relation (or at least a part of the database relation) does. For instance, each button in one chatbot message is structured as follows:

• information 1; information 2; information 3.

As described, in SAP CAI, buttons can be generated by tuple values of a database relation. A tuple usually consists of various attribute values. To partition the information of a button, specific button information, in our example the timestamp which assembles the value of a button, is matched with information stored in the database (usually matched with the unique key). Thereby a button is assigned to a distinct database tuple, so that the explicit attribute values of the distinct tuple can be extracted and processed separately.

Since we can now access the attribute values of a tuple that has been assigned to the selected button, we can access the button’s individual information separately.

Exactly this is for example the case in my chatbot’s skill favselect_ask. favselect_ask offers the chat partner a quick access to its stored personal time recording favourites (Figure 8), which consist of activity number; activity description; working location.

Figure 8

To store such favourites in the first place, the chat partner has the ability to appoint favourites whenever recording working times, as shown in figure 9.

Figure 9

In doing so, the respective time recordings receive either the attribute favourite’s Boolean value true or false in the database. With the help of this attribute, the stored favourites can be accessed via a selective API call set thereon. The thereby obtained attributes activity number, activity description, working location will then be presented to the chat partner (Figure 8). Buttons are generated by a loop which calls the attributes from a prior seeded API GET call (Figure 10).

Figure 10

As button type, postback is used. When clicking on a button, the chat partner “posts back” the assigned value of the respective button. As value, each button has been assigned the timestamp, which recorded the time (accurate to the second), at which the time acquisition was originally saved, which belongs to the respective favourite.

In the subsequent skill fav_post, an API GET call is applied again to receive the so far recorded times. Further on, loops are implemented which run through these recorded times and check which time recording belongs to the postback value timestamp. The activity number, activity description and working location of the fitting time record are then memorized on their own. From now on, involved data can be processed separately. The activity number for instance can be posted into the respective database’s slot. In figure 11 you can for instance see the loop which runs for memorizing the activity number.

Figure 11

2.2) Partition via String-Splitting

In my chatbot, I also wanted to implement a skill to record times via a shortcut, so that the chat partner simply enters its information all together in a single message. Intuitively, it isn’t possible to therefore manage data handling via information matching as outlined in the previous subsection.

Instead, SAP CAI enables you to utilize the Handlebars template language’s String-splitting function.

When the chat partner enters “shortcut”, the skill shortcut is triggered and asks the chat partner to type in required information in an explicit format, surrounding separate information by quotation marks, and separating information by exclamation marks, as you can see below in Figure 12.

Figure 12

If the chat partner then replies in accordance with the required format, its information will be registered and afterwards incorporated in the database (Figure 13).

Figure 13

Handlebars String-splitting function splits Strings at defined symbols and creates an Array consisting of the separated parts of the original String. In figure 14, you can see that the chat partner’s entered input nlp.source is split at each exclamation mark. The received array is memorized in the memory field input.

Figure 14

I already mentioned, that applying the String-splitting function has some practical design drawbacks. In the utilized JSON value format, an Array has to explicitly consist of Strings, and Strings are thereby indicated by being surrounded by quotation marks. However, the Handlebars String-splitting function simply splits the entered String and creates an array of elements which are not surrounded by quotation marks. JSON value format hence doesn’t accept the generated array. When for instance entering information as in Figure 15 (instead of as in Figure 13), SAP CAI generates a warning, as in Figure 16.

Figure 15

Figure 16

Therefor the skill shortcut assertively asks the chat partner to put each information input in quotation marks.

Nevertheless, the data-separating “!” symbol-combination is typed in easy and fast, as “ and ! are located directly next to each other on the keyboard 😉

3) Invalid Chat Entries

Chatbots are often confronted with the challenge, that the chat partner’s entered information has to conform to certain formalities or specifications. The matching of the entered information and the requested schemas is done, for example, by matching the input with specific entities. The question is now, how to configure the chatbot’s behaviour, when inappropriate information were entered by the chat partner. This works through SAP CAI’s memory function and a customized fallback skill.

In the setup of an exemplary chatbot that handles inappropriate inputs, we basically assume that skill A asks the chat partner for information and, after the chat partner has entered the requested information, skill B checks whether the information satisfies certain schemas. If this is the case, skill B continues the conversation.

In skill A, a new memory field C is first assigned the value false. In my time recording chatbot, it looks as follows. The chat partner’s entered working duration has to conform to certain acceptable values. In the skill duration_ask, which asks the employee to state its working duration, a memory field wait_arbeitsdauer in the Action section is given the Boolean value false (Figure 17).

Figure 17

As usual when matching input information and entities, skill B is now triggered if the intent incorporating the entity to which the input information is assigned, is present. In my chatbot for example, the intent @arbeitszeiten (German term for working hours) incorporates values of the entity which consists of acceptable working duration values (Figure 18).

Figure 18

In the requirement section of skill B, the memory field C is now set true (Figure 20). Precondition is here as well, that the entity with the acceptable values – in my case #arbeitsdauer (German term for working duration) – was addressed (Figure 19).

Figure 19

Figure 20

In the action section of skill B, not only the addressed entity is specified as a condition, but also that the memory field C must have the value true (Figure 21). Consequently, the chatbot conversation will be continued as usual by skill B if input information has satisfied the requested scheme.

Figure 21

However, if the respective entity was not addressed by the chat partner’s input, i.e. the information was not suitable, the value true is not assigned to the memory field C in the requirements of skill B – the value instead remains false. In the skill fallback, the action section contains a group that contains the condition that the memory field C is assigned to the value false. This action group now informs the chat partner that its input was inappropriate and redirects again to skill B with the request to first make a correct input.

As shown in figure 22, my chatbot for instance notifies the chat partner that the entered working duration is invalid, and asks the chat partner to enter a valid working duration. To check the entered information, the chatbot again activates the skill number_ask.

Figure 22

Summary

In summary, in SAP CAI it is possible to handle chat partner information well, if you apply some smart tricks. Free text inputs and invalid chat entries can be handled via SAP CAI’s memory function and information can be either partitioned via information-matching or via String-splitting.