Skip to content

Commit cfae0b9

Browse files
Merge pull request #33 from rwth-acis/release-v1.0.1
Release v1.0.1
2 parents eb1718a + 30cf92b commit cfae0b9

25 files changed

+1510
-2215
lines changed

Dockerfile

Lines changed: 12 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
FROM node:12
1+
FROM node:10
22

33
ENV YJS_RESOURCE_PATH "/socket.io"
44
ENV PORT 8070
@@ -7,28 +7,33 @@ WORKDIR /usr/src/app
77

88
RUN apt-get update
99
RUN apt-get install -y --allow-unauthenticated --no-install-recommends supervisor git nginx dos2unix
10-
RUN npm_config_user=root npm install -g bower grunt-cli grunt polymer-cli gulp
10+
RUN npm_config_user=root npm install -g grunt-cli grunt polymer-cli gulp
1111

1212
ARG src="Utilities Frontend/docker/supervisorConfigs"
1313
ARG srx="Utilities Frontend"
1414
COPY ${src} /etc/supervisor/conf.d
1515

16-
# TODO: Use master branch
1716

18-
RUN git clone https://github.com/rwth-acis/syncmeta.git
17+
WORKDIR /usr/src/app
18+
COPY ${srx}/syncmeta syncmeta
19+
20+
1921
WORKDIR /usr/src/app/syncmeta
20-
RUN git checkout chat-assessments
22+
RUN npm install
23+
RUN cp -a node_modules/@rwth-acis/syncmeta-widgets/. widgets/
24+
RUN cp -a node_modules/. widgets/node_modules/
2125
COPY ${srx}/docker/_bot_widget.tpl /usr/src/app/syncmeta/widgets/src/widgets/partials/
2226
COPY ${srx}/docker/bot_widget.js /usr/src/app/syncmeta/widgets/src/js/
2327
COPY ${srx}/docker/Gruntfile.js /usr/src/app/syncmeta/widgets/
2428
COPY ${srx}/docker/yjs-sync.js /usr/src/app/syncmeta/widgets/src/js/lib/
2529
WORKDIR /usr/src/app/syncmeta
26-
RUN cd widgets && rm package-lock.json && npm install && bower install --allow-root
30+
RUN cd widgets && npm install
2731

2832
WORKDIR /usr/src/app
2933
COPY ${srx} .
3034
WORKDIR /usr/src/app/app
31-
RUN npm install && bower install --allow-root
35+
ADD "https://www.random.org/cgi-bin/randbyte?nbytes=10&format=h" skipcache
36+
RUN npm install
3237

3338
WORKDIR /usr/src/app
3439
ARG srt="Utilities Frontend/docker/docker-entrypoint.sh"

README.md

Lines changed: 26 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -103,9 +103,12 @@ After a first chat-interaction with the bot, there also is the possibility to cr
103103

104104
![communicationstate](READMEImages/leadsToModelling.png)
105105

106-
The Intent attribute of the follow up Incoming Message elements can remain empty as the leadsTo relation will take care of forwarding the state. For these messages to be reachable from the initial state, the Messenger will again need to connect to these elements using the "generates" relation and the elements will also need to have the Intent attribute set. Once there is no follow up message the conversation path will be quit and the conversation will go back to the initial state. If no fitting Intent is recognized, the bot will simply send the default message.
106+
The Intent attribute of the follow up Incoming Message elements can remain empty as the leadsTo relation will take care of forwarding the state. For these messages to be reachable from the initial state, the Messenger will again need to connect to these elements using the "generates" relation and the elements will also need to have the Intent attribute set. Once there is no follow up message the conversation path will be quit and the conversation will go back to the initial state. If no fitting Intent is recognized, the bot will simply send the default message. If one of the leadsTo relation is empty, this path will be taken if no fitting Intent was found while in a conversation.
107107
Continuing the previous greeting example, the user could have changed the bot's initial message to "Hello :), how was your day?". To model a fitting response, the user added the Intents "positiv" & "negativ", added new Incoming Message elements with the leadsTo relation and added Chat Responses with fitting answers. The bot would now, after asking the user about their day, expect a positiv or negativ answer and respond accordingly.
108108

109+
### Create communication state with service
110+
In addition to modelling simple textual responses, it is also possible to let the bot send a file to the user as a response. For that purpose, the Chat Response Element contains two additional attributes called "FileURL" and "ErrorMessage". FileURL should simply contain the URL to the file's download page. ErrorMessage should simply contain a message, which will be sent to the user in case an error occurs when retrieving the file.
111+
Currently, the placeholder "menteeEmail" is available for the FileURL attribute. If "menteeEmail" is contained in the FileURL, it will be replaced by the user's email address.
109112
### Create communication state with service
110113
There is the possiblity to let users communicate and send messages to a specific triggered service for a certain period of time, depending on the service.
111114
During this communication state the service will receive every user message and also have the possibility to communicate with the user.
@@ -128,3 +131,25 @@ The `text` attribute represents the service's response to the user.
128131

129132
The `closeContext` attribute is a boolean value which informs the Social Bot Manager if the communication state is to be maintained or stopped. (Note that, if no closeContext attribute is found, the communication state will automatically be stopped.)
130133

134+
### Sending Files to a Service
135+
When modelling the conversation between bot and user, there is also the possibility to let the bot expect files from a user. To be precise, a user could trigger a service by sending a file, which would get forwarded to the service for further processing. Lets take our communication state from before and presume that the Bot Action Element is a service which expects a file:
136+
137+
![communicationstate](READMEImages/communicationState.png)
138+
139+
In this case, we would like the service to be triggered only if a file was sent. To do this, we have the "IsFile" bool attribute in the Incoming Message Element. If the IsFile attribute is checked and no Intent is given, then the Bot Action will be triggered regardless of the file's name (given that a file was sent). If an Intent is given, then Intent extraction will be done on the file's name and see if the extracted Intent corresponds to the Intent given as attribute in the Incoming Message Element. This for example allows the bot to understand specific file name formats, such as the following:
140+
141+
![communicationstate](READMEImages/AssignmentIntentExamples.png)
142+
143+
144+
If a file is sent to a triggered service, it will first be encoded into base64 encoding. Afterwards, the JSON body sent to the triggered service will contain following attributes:
145+
146+
```json
147+
{
148+
"fileBody": "String of base64 encoding",
149+
"fileName": "String",
150+
"fileType": "String"
151+
}
152+
```
153+
154+
Note that if a service wants to send a file to a user, it will also need to encode the file in base64 encoding and the response will additionally need to contain the 3 just shown attributes.
155+
2.24 KB
Loading

0 commit comments

Comments
 (0)