Final Project — Java Full Stack

So, I joined IBM in the month of June, this year and was pretty much excited, but I never ever, ever ever imagined this was going to be the toughest training I have undergone till date!😂😢.

So there I was in Stackroute, Kormangala, for my training in Java Full Stack. Our entire batch was divided into 3 teams. Each team had to develop and deploy a product in the end. For my team, the product was — an easy to use and pluggable Helpdesk System. One of the teams in our batch had to develop an app call Umove(basically a bike renting system). So our team, had the task of integrating our helpdesk system with the Umove team.

We decided to name our app as “Nikolaj”(which means victory to the people). So we developed the app using Spring boot as backend and Angular in the frontend. Below is a concise description of our app.

• First of all we have a bot named Optimus,(we used IBM watson, and along with it, Stanford NLP), which is supposed to resolve a particular query by a user.
• The bot is supposed to resolve a user’s query based on some intents and after that execute some commands. The intent is identified by the bot itself based on the user’s query.
• If the bot has a particular intent, and it is confident about the command(each command stored with the bot has a confidence level associated with it, which when greater than 90%, is executed by the bot), it executes the command and resolves the query and then, asks the user for a rating.
• If the bot is unable to resolve a particular query, there are 2 cases. Either the intent and command both are unavailable with the bot or the bot has the command with it, but is not confident enough to execute it.
• In such a case, the bot creates a ticket for that particular query and sends it to the queue(We used RabbitMQ in our project for such queueing and messaging services).
• Here comes the role of the CSR(Customer Support Representative). As stated earlier, whenever the bot is unable to resolve a query, a ticket is raised and sent to the queue. On the CSR’s side, he/she is supposed to resolve a particular query by assigning himself/herself a ticket. This can be done with the click of a button.
• Whenever a CSR assigns himself a ticket, he is redirected to the ticket details page, where he is able to see the ticket details namely, the user who raised the ticket, user’s query, ticketID and also the previous chat which the user had with the bot.
• The CSR then goes on to resolve the user’s query by chatting with him, and based on the query, he can also execute a command, which will give him a response, which can be shared with the user as a response to their query.
• Now, if the bot does not have a command or intent with it, for a particular query, the CSR is provided with the option to provide a suggestion(which is optional) for the names of the command and intent.
• If the bot is not confident enough for a particular command, it will suggest that particular command to the CSR. If the CSR executes that command and the results obtained after executing it resolve the user’s query, the CSR is supposed to give a success rating to that command which will in turn update the confidence of the bot for that particular command.
• For this helpdesk system, we also have 2 other aspects — the command framework and reports.
• The command framework basically is a storehouse of all the commands that are supposed to be executed by the bot/CSR or referred to by the CSR. It also contains a sunburst chart, depicting the queries which have no command/no intent.
• The other part is the reports — there are different kinds of reports, namely ticket status reports(which show the number of tickets in the various states — open, closed, engaged), Service reports, which are calculated based on the service which may have an issue. These reports help provide an insight to the service which integrates our helpdesk system, about the different areas where they might want to improve their app.

The main motive of our app was to help the services elevate their profits over a period of time by eliminating the need to maintain customer support representatives. This can achieved gradually as the bot gets trained to resolve the user’s queries by executing commands.

Following is the architecture diagram of our app:

Architecture diagram for Nikolaj

The technologies used in this project are:

• Angular 8: for frontend.
• SpringBoot: for backend.
• Docker: for containerizing our microservices.
• RabbitMQ: for queueing and messaging services.
• Databases: MongoDB, Neo4j and Redis

P.S. The final product was deployed on AWS VM, which at present, is not active (as the VMs were assigned to the respective teams only for deployment and one time demonstration purposes).

Following is the code for this project. Do give it a star, if you like it!

lakshyajit165/Nikolaj

Following are some of the glimpses from the day of our presentation:

The Graduation Day!