Bitrix24 - CRM or not only?
Often the best solutions come from where they are not expected at all. One has only to look at everyday things from a slightly different angle, just as the light bulb begins to light up above.
Exactly the same story happened with our team, when we received the task to develop a system for managing the schedule of classes and accounting for student performance of college students.
Looking ahead, as a result, we managed to solve the problem by developing applications for cloud-based CRM Bitrix 24.
')
Using the example of our case, we would like to show how this crm can be used, at first glance, not quite for standard purposes. We dare to hope that our experience will be useful, faced with the task of custom integration bitrix24 and at least inspire such solutions.
The project became a logical continuation of the site, which we launched for the client earlier.
The site already had a schedule, but there was a lack of convenient management and an internal, personalized space for participants in the learning process - teachers and students.
Having collected basic requirements, we received approximately the following list:
Bitrix24 is, frankly, our work environment. We know it well from the point of view of the user. Here we conduct our projects, exchange documents, communicate with clients, and conduct our tasks in the tracker.
We also, by the time the task arrived, had some experience in developing applications for b24:
But at that time we didn’t know more or less serious integrations, except for the kanban boards from the company Siberiks, and didn’t implement them.
Applications in bitrix24 are your development, which can be hosted and run on your site, but built into the bitrix24 portal via Iframe. This integration allows you to use Oauth 2.0 authorization and provides work with the portal data through the API.
Bitrix24 in this case will be a “black box”, you can implement your decisions as you please. We, for example, succeeded on the React + Laravel stack, closer to the end of the article.
An application in bitrix24 is a solution of tasks that cannot be solved by means of the functionality existing in the service.
Ie if you, for example, are not satisfied with the “basic” display of the task list or any other entity, you can implement your own application in which you can display the list of tasks as you need. If you need to automatically perform some manipulations with the data of bitrix entities or their characteristics, then this can also be solved by means of custom solutions.
But bitrix24 is first of all a CRM system, where does the portal for the automation of the educational process come from?
Using bitrix24 as a platform for the implementation of our task, in fact, it looked tempting.
Almost out of the box we got a solution to the problem of communication between students and teachers through the use of the functionality of working groups . You just had to look at the working groups from the right angle.
The group can be educational - to combine the curator-teacher and students, allowing you to exchange local information for the group.
A group can be subject - physics, chemistry ... and so on. Thanks to b24's capabilities, in such a group you can easily organize the knowledge domain of information on a subject. For this there is all the necessary functionality:
Having a platform for developing chatbots, which are automatically available on the mobile version of the portal, immediately suggested the creation of at least a bot that would provide information about the schedule of classes and inform about its changes, in addition to sms notifications.
Under the requirements that remained uncovered by the platform's functionality, we decided to develop iframe applications.
There were no working examples of such an implementation to show “it will be approximately like this.” Therefore, a small sketch of the concept was created. We have compiled a document briefly describing how we see the implementation of the project on bitrix24. This played an important role in the development decision.
Determined with the requirements and tools, now you can consider the development process itself.
The description sequence will be as follows:
So let's go!
As we said earlier, we have three separate entities. Functioning website, bitrix CRM system and iframe application that we are going to develop. The data contained in these entities can be schematically depicted in the form of the following mind map.
We needed to “make friends” with these diverse entities and resolve the issue of data integrity.
Since, the site has already formed and operated a database for all directories and the schedule itself, we decided to simply implement the REST API for it so that this data can be obtained in our bitrix24 application.
For each of the user roles, a separate application was implemented. Under the scheme will be described why this was done.
We decided to distribute the functionality this way, because if the application were one, we would have to implement the logic of access distribution. Students do not need access to the journal with grades, the teacher does not need to manage the schedule, etc. In general, this is not a terrible task, but we use an environment in which it is possible to set up an application access policy at the level of user groups out of the box. In addition, we consider bitrix24 as a development platform - why not use the existing functionality.
Currently, there are 4 departments in the application: portal administrators, teachers, students and chat bots.
Initially, before detailing the requirements and before deciding to implement a full-fledged application, the task was to change the schedule management system, since the implementation on the site side turned the work on scheduling into hellish agony and took a lot of time.
In fact, this is adding / editing records to the database via the bitrix information block interface.
Ie for entering classes in the schedule required to create an element in the tabular interface
In the process of finding a more convenient solution, we thought - what could be more convenient than editing the schedule in an interface that looks like a schedule?
And developed a functional prototype
And then they added colors, drag & drop, sidebars and notifications. And painted an owl .
For a more detailed view of the application, we recorded a small screencast , it displays part of the solution functionality.
The functionality that is implemented:
The requirements also included sending notifications in case of schedule changes. Said - implemented. Notifications are delivered by chat-bot (also available in the mobile application) via sms gateway and fast in the news feed of the group (well, for sure).
By default, notifications are sent to students and teachers whose groups have changed, but the administrator can also select a list of recipients. The texts of the notifications themselves are generated from the template, but they can easily be changed.
Another task that we solved in the administrator interface is mapping, a bunch of teachers and site groups with teachers and groups in Bitrix. It is for social. groups bitrix24 is determined by what schedule to show the teacher, what the student sees. Ie the data in the API, and we filter them according to the data from bitrix24. To do this, we implemented a special CRUD interface in which these dependencies were added.
The administrator, to create a connection, can choose a teacher from the ones already available on the site
or invite a new one by sending an email notification
The administrator’s tasks also include the management of reference data, from which the schedule is assembled - subjects, teachers, and audiences. In general, this work can be done in the admin interface of the site, but in order for the administrator to be in a single environment, we implemented the interface directly in the application.
For the teacher, we have developed an application that consists of three main parts: Schedule, Journal and Student Performance.
On the Schedule page, the teacher can view his schedule, with a filter by the groups in which he teaches. In addition, the teacher can create an unlimited number of journal entries of a certain type (lecture, seminar, laboratory work, practice, homework, etc.) based on a schedule entry.
In the Journal, the teacher can record information about grades, student attendance and set homework.
Creating, deleting, editing classes, as well as chat with a student look like this:
The most important thing a student needs to know is the class schedule, progress, and homework. By analogy with the administrator and teacher interfaces, a page for viewing class schedules was created. Slightly changed the appearance and removed extra functionality.
On the student achievement page, the student views current grades and the average grade for subjects. There is also a semester filter.
For the time being, we have assigned the chat bot the simple duties of sending a message about a change in the schedule and sending a schedule grid on request. You can request a schedule for a specific day or for the whole week. Chat bot, as a service available in the chat rooms of the portal, is automatically available on the mobile version of the portal - extremely convenient. In this way, we have provided easy access to the schedule and from mobile devices.
There was a great temptation to use such an image as a chat bot icon.
But we did not, believing that it is too ironic work.
We are jealous of the results of our work, application errors and user problems when working with our application hurts our hearts.
To ensure the cardio-safety and quality of the application, we use a set of measures.
We use 3 independent servers for testing and operation development.
In the development of a model of git-flow .
For auto testing, we use codeception , test user scripts and api data from the site.
To build the application on staging and production, we use gitlab-ci, placing the files in the required application directories (we actually have several of them, see above), run the build-front npm run build, composer and auto tests.
No matter how hard we try to cover everything with tests, there will always be exceptional situations. One way or another, mistakes cannot be avoided. If they can not be avoided, then surely you can somehow control?
Probably, we all got used to the fact that if an error suddenly occurred on the server, then it is recorded in the logs and after it can be diagnosed. But what about the mistakes that occur on the front end? Everything that happens with the client, he remains. If the error is quite critical, then you can learn about it, through the angry customer feedback. This is clearly not our method.
To catch errors that may occur during the work of the “production” application, we use and terribly rejoice at this service https://sentry.io . This service builds both client and server errors. All errors are tracked and must be reported.
As a bonus, we set up integration in slack, so that at the moment of the occurrence of the precedent, a corresponding notification appears in the project channel. Thanks to this, we can find out about errors before the customer creates a ticket in the support system, and take prompt action if the situation is critical.
To track the state of production of the machine is used zabbix . Tracked all the basic parameters of the machine from availability to use of resources.
When forming a site - portal relationship, scheduling, conflicts may arise that violate the integrity of the data. For example, there may be a situation when one teacher is assigned several classes by mistake on the same day and the same couple.
Man is not a robot. For everything just will not follow. To solve such problems, we collected the “Control” diagnostics screen, in which we placed in the form of a checklist a list of checks and their result.
From a technical point of view, the whole project is quite complex, so we approached the choice of technologies thoroughly. As a server programming language, we decided to use PHP, coupled with the MySQL database. This bunch is very popular in the world of web development, moreover, is well known to our team.
Since the project is based on the use of CRM Bitrix 24, it is very much tied to the use of the portal API. Very often the call of various methods will be used, therefore it is necessary to simplify this part to the maximum. For this purpose, we decided to use bitrix24-php-sdk , which provides a convenient object approach. At the same time a little involved in the development of this library.
Writing native PHP in 2017 is far from the best option, especially for a project of this size. Therefore, it was necessary to choose a framework. From the requirements - the presence of MVC, ORM, migrations and seeders, work with queues. Under these requirements, many Laravel, YII2, Zend, Phalcon and other frameworks are obscure. We decided to choose Laravel, because our team had more experience working with him.
From the point of view of the frontend, the choice of a good tool was no less important. We focused on a bunch of React / Redux / React Router.
React is based on a component approach, which is very suitable for us. It is convenient to implement one component and then reuse it in several places of the application.
So, for example, it was with a component for displaying a lesson schedule. In general, it is the same for a student, and for the administrator and teacher. All distinctive features are well configured through the properties of the components.
React also has a huge community and a large number of different components implemented. The react dnd component helped us a lot when implementing the job transfer mechanism.
For writing styles, we used the preprocessor-Less, which significantly reduces the number of lines of CSS-code, through the use of hierarchical structures, impurities and variables.
For the assembly of the project we are responsible Webpack. In fact, the choice of the collector was not so fundamental, since we did not have any special moments or requirements.
Working on the project, we got experience that is difficult to describe in one post. The disclosure of individual issues is wiser to make separate publications.
We have some content plan for the near future, in particular, we would like to tell and share the boilerplate on the laravel-react-bitrix24 api bundle, which we formed in the process. If some moments arouse the interest of the community and they are not able to be disclosed in the framework of comments, we will be happy to share knowledge and experience in new materials.
Exactly the same story happened with our team, when we received the task to develop a system for managing the schedule of classes and accounting for student performance of college students.
Looking ahead, as a result, we managed to solve the problem by developing applications for cloud-based CRM Bitrix 24.
')
Using the example of our case, we would like to show how this crm can be used, at first glance, not quite for standard purposes. We dare to hope that our experience will be useful, faced with the task of custom integration bitrix24 and at least inspire such solutions.
Task
The project became a logical continuation of the site, which we launched for the client earlier.
The site already had a schedule, but there was a lack of convenient management and an internal, personalized space for participants in the learning process - teachers and students.
Having collected basic requirements, we received approximately the following list:
- schedule management system
- sending SMS notifications about changes in the schedule
- attendance records
- communication between students and teachers, including the exchange of documents
Bitrix24 is, frankly, our work environment. We know it well from the point of view of the user. Here we conduct our projects, exchange documents, communicate with clients, and conduct our tasks in the tracker.
We also, by the time the task arrived, had some experience in developing applications for b24:
- we made our application that solves the problem of monitoring the load on technical support
- released the first commercial chat bot for b24
- put together an end-to-end analytics solution using google analytics and call tracker
But at that time we didn’t know more or less serious integrations, except for the kanban boards from the company Siberiks, and didn’t implement them.
Applications in bitrix24 are your development, which can be hosted and run on your site, but built into the bitrix24 portal via Iframe. This integration allows you to use Oauth 2.0 authorization and provides work with the portal data through the API.
Bitrix24 in this case will be a “black box”, you can implement your decisions as you please. We, for example, succeeded on the React + Laravel stack, closer to the end of the article.
An application in bitrix24 is a solution of tasks that cannot be solved by means of the functionality existing in the service.
Ie if you, for example, are not satisfied with the “basic” display of the task list or any other entity, you can implement your own application in which you can display the list of tasks as you need. If you need to automatically perform some manipulations with the data of bitrix entities or their characteristics, then this can also be solved by means of custom solutions.
But bitrix24 is first of all a CRM system, where does the portal for the automation of the educational process come from?
Using bitrix24 as a platform for the implementation of our task, in fact, it looked tempting.
Almost out of the box we got a solution to the problem of communication between students and teachers through the use of the functionality of working groups . You just had to look at the working groups from the right angle.
The group can be educational - to combine the curator-teacher and students, allowing you to exchange local information for the group.
A group can be subject - physics, chemistry ... and so on. Thanks to b24's capabilities, in such a group you can easily organize the knowledge domain of information on a subject. For this there is all the necessary functionality:
- file storage
- news feed
- wiki
- chats
Having a platform for developing chatbots, which are automatically available on the mobile version of the portal, immediately suggested the creation of at least a bot that would provide information about the schedule of classes and inform about its changes, in addition to sms notifications.
Under the requirements that remained uncovered by the platform's functionality, we decided to develop iframe applications.
There were no working examples of such an implementation to show “it will be approximately like this.” Therefore, a small sketch of the concept was created. We have compiled a document briefly describing how we see the implementation of the project on bitrix24. This played an important role in the development decision.
Appendix 24
Determined with the requirements and tools, now you can consider the development process itself.
The description sequence will be as follows:
- entity description
- application structure description
- admin interface
- teacher interface
- student interface
- stack of technologies and processes used
So let's go!
Main entities
As we said earlier, we have three separate entities. Functioning website, bitrix CRM system and iframe application that we are going to develop. The data contained in these entities can be schematically depicted in the form of the following mind map.
We needed to “make friends” with these diverse entities and resolve the issue of data integrity.
Since, the site has already formed and operated a database for all directories and the schedule itself, we decided to simply implement the REST API for it so that this data can be obtained in our bitrix24 application.
Solution structure on the bitrix24 side
For each of the user roles, a separate application was implemented. Under the scheme will be described why this was done.
We decided to distribute the functionality this way, because if the application were one, we would have to implement the logic of access distribution. Students do not need access to the journal with grades, the teacher does not need to manage the schedule, etc. In general, this is not a terrible task, but we use an environment in which it is possible to set up an application access policy at the level of user groups out of the box. In addition, we consider bitrix24 as a development platform - why not use the existing functionality.
Currently, there are 4 departments in the application: portal administrators, teachers, students and chat bots.
Structure back-end
To implement the scheme from 3 applications at the backend level, we formed the following requirements for ourselves:
- Each application must have its own unique url (entry point)
- Each application must have a unique identifier and an access key (bitrix24 is generated when creating the application, required when working)
- Using one git repository
- All three applications must have a common database (all three applications work with the same entities)
As a result, we got:
- The code of each application is placed in the directory of a separate virtual host.
- All characteristic, configuration information is stored in each application's .env file.
- Under git, we only host the admin application. Hosts of student and teacher applications contain a minimum of entities, only to “get” laravel, which is used as a framework on the backend. In this case, the entities that are stored on the main host and are needed in the work of all applications are simply linked by symlink. Each application has its own bundle js and css, located again in the directory of the administrative application and connected through the entry points of the respective applications.
- All 3 applications have one database. So that there is no conflict with the migrations and the seeds, the database directory is linked from the student and teacher hosts to the git directory in the admin application.
Admin interface
Work with the schedule
Initially, before detailing the requirements and before deciding to implement a full-fledged application, the task was to change the schedule management system, since the implementation on the site side turned the work on scheduling into hellish agony and took a lot of time.
In fact, this is adding / editing records to the database via the bitrix information block interface.
Ie for entering classes in the schedule required to create an element in the tabular interface
In the process of finding a more convenient solution, we thought - what could be more convenient than editing the schedule in an interface that looks like a schedule?
And developed a functional prototype
And then they added colors, drag & drop, sidebars and notifications. And painted an owl .
For a more detailed view of the application, we recorded a small screencast , it displays part of the solution functionality.
The functionality that is implemented:
- create \ edit \ delete class
- change of occupation in the schedule grid
- the creation of coupled activities in the same pair
The requirements also included sending notifications in case of schedule changes. Said - implemented. Notifications are delivered by chat-bot (also available in the mobile application) via sms gateway and fast in the news feed of the group (well, for sure).
By default, notifications are sent to students and teachers whose groups have changed, but the administrator can also select a list of recipients. The texts of the notifications themselves are generated from the template, but they can easily be changed.
How it works
Since the process of sending a large number of messages may be delayed, we have compiled the implementation of sending notifications based on the gearman task manager . Ie there are several workers running as background who are in a constant state of readiness to accept the task of sending, be it an SMS or chat bot message.
So we got:
- control over resources - “wokers” are hanging as much as we can allow ourselves according to resource and task
- speed of work - due to the "parallel" execution, we can process quickly a large number of messages
- control over the sending of messages - in the event of a delivery error, we can track the status of the task and, for example, initiate a resend
CRUD links
Another task that we solved in the administrator interface is mapping, a bunch of teachers and site groups with teachers and groups in Bitrix. It is for social. groups bitrix24 is determined by what schedule to show the teacher, what the student sees. Ie the data in the API, and we filter them according to the data from bitrix24. To do this, we implemented a special CRUD interface in which these dependencies were added.
The administrator, to create a connection, can choose a teacher from the ones already available on the site
or invite a new one by sending an email notification
Work with reference books
The administrator’s tasks also include the management of reference data, from which the schedule is assembled - subjects, teachers, and audiences. In general, this work can be done in the admin interface of the site, but in order for the administrator to be in a single environment, we implemented the interface directly in the application.
Notifications
To inform the user about various events, the application uses about 25 notifications of 4 types:
- success
- warning
- pending
- error
We could confine ourselves to a single “placement” of displaying notifications - the upper right corner, but unfortunately (or maybe even fortunately) we faced the limitations of embedded Iframe applications.
The standard Iframe block height on the bitrix portal was about 800px, it was not possible to fit something efficient on such a scrap. When this value was exceeded, the iframe of the block had its own vertical scrollbar. Two Scrollbar per page? - "Too much!". The benefit of the bitrix library was the built-in fitWindow method, which stretches the iframe block in accordance with the size of its contents.
We got rid of the second scroll, but also the possibility of using fixed positioning. And therefore we added notifications near the source of their initiation.
And this is how they look:
Error saving teacher record
Successful storage of item name
Attempt to remove something important
With a long request, the button appears pending-state
The use of such notifications has a very positive impact on user perception, because the application has become more lively and responsive.
Teacher interface
For the teacher, we have developed an application that consists of three main parts: Schedule, Journal and Student Performance.
On the Schedule page, the teacher can view his schedule, with a filter by the groups in which he teaches. In addition, the teacher can create an unlimited number of journal entries of a certain type (lecture, seminar, laboratory work, practice, homework, etc.) based on a schedule entry.
In the Journal, the teacher can record information about grades, student attendance and set homework.
Creating, deleting, editing classes, as well as chat with a student look like this:
Student interface
The most important thing a student needs to know is the class schedule, progress, and homework. By analogy with the administrator and teacher interfaces, a page for viewing class schedules was created. Slightly changed the appearance and removed extra functionality.
On the student achievement page, the student views current grades and the average grade for subjects. There is also a semester filter.
Chat bot
For the time being, we have assigned the chat bot the simple duties of sending a message about a change in the schedule and sending a schedule grid on request. You can request a schedule for a specific day or for the whole week. Chat bot, as a service available in the chat rooms of the portal, is automatically available on the mobile version of the portal - extremely convenient. In this way, we have provided easy access to the schedule and from mobile devices.
There was a great temptation to use such an image as a chat bot icon.
But we did not, believing that it is too ironic work.
Quality control
We are jealous of the results of our work, application errors and user problems when working with our application hurts our hearts.
To ensure the cardio-safety and quality of the application, we use a set of measures.
Build and test
We use 3 independent servers for testing and operation development.
In the development of a model of git-flow .
For auto testing, we use codeception , test user scripts and api data from the site.
To build the application on staging and production, we use gitlab-ci, placing the files in the required application directories (we actually have several of them, see above), run the build-front npm run build, composer and auto tests.
Error control
No matter how hard we try to cover everything with tests, there will always be exceptional situations. One way or another, mistakes cannot be avoided. If they can not be avoided, then surely you can somehow control?
Probably, we all got used to the fact that if an error suddenly occurred on the server, then it is recorded in the logs and after it can be diagnosed. But what about the mistakes that occur on the front end? Everything that happens with the client, he remains. If the error is quite critical, then you can learn about it, through the angry customer feedback. This is clearly not our method.
To catch errors that may occur during the work of the “production” application, we use and terribly rejoice at this service https://sentry.io . This service builds both client and server errors. All errors are tracked and must be reported.
As a bonus, we set up integration in slack, so that at the moment of the occurrence of the precedent, a corresponding notification appears in the project channel. Thanks to this, we can find out about errors before the customer creates a ticket in the support system, and take prompt action if the situation is critical.
Monitoring
To track the state of production of the machine is used zabbix . Tracked all the basic parameters of the machine from availability to use of resources.
Diagnostics
When forming a site - portal relationship, scheduling, conflicts may arise that violate the integrity of the data. For example, there may be a situation when one teacher is assigned several classes by mistake on the same day and the same couple.
Man is not a robot. For everything just will not follow. To solve such problems, we collected the “Control” diagnostics screen, in which we placed in the form of a checklist a list of checks and their result.
How does the diagnosis work
Diagnostics would be nice to run in situations that could potentially create problems, for example, when creating a schedule. It is possible to do on-site verification right away, but we applied a more flexible and scalable solution.
We planned the check-list of control as expandable. Some operations can be quite resource intensive. In order not to block the operation of the application with diagnostics, using gearman, we send the task to be checked in a queue, when a “potentially dangerous” event occurs and the administrator starts the application for the first time.
In case of an error on one of the checks, we launch our “evil robot” with a strong recommendation to go to the control section.
We did not make diagnostics in “assembly” tests, because the developer may not solve, for example, a schedule conflict.
What we used in our work
From a technical point of view, the whole project is quite complex, so we approached the choice of technologies thoroughly. As a server programming language, we decided to use PHP, coupled with the MySQL database. This bunch is very popular in the world of web development, moreover, is well known to our team.
Since the project is based on the use of CRM Bitrix 24, it is very much tied to the use of the portal API. Very often the call of various methods will be used, therefore it is necessary to simplify this part to the maximum. For this purpose, we decided to use bitrix24-php-sdk , which provides a convenient object approach. At the same time a little involved in the development of this library.
Writing native PHP in 2017 is far from the best option, especially for a project of this size. Therefore, it was necessary to choose a framework. From the requirements - the presence of MVC, ORM, migrations and seeders, work with queues. Under these requirements, many Laravel, YII2, Zend, Phalcon and other frameworks are obscure. We decided to choose Laravel, because our team had more experience working with him.
From the point of view of the frontend, the choice of a good tool was no less important. We focused on a bunch of React / Redux / React Router.
React is based on a component approach, which is very suitable for us. It is convenient to implement one component and then reuse it in several places of the application.
So, for example, it was with a component for displaying a lesson schedule. In general, it is the same for a student, and for the administrator and teacher. All distinctive features are well configured through the properties of the components.
React also has a huge community and a large number of different components implemented. The react dnd component helped us a lot when implementing the job transfer mechanism.
For writing styles, we used the preprocessor-Less, which significantly reduces the number of lines of CSS-code, through the use of hierarchical structures, impurities and variables.
For the assembly of the project we are responsible Webpack. In fact, the choice of the collector was not so fundamental, since we did not have any special moments or requirements.
Conclusion
Working on the project, we got experience that is difficult to describe in one post. The disclosure of individual issues is wiser to make separate publications.
We have some content plan for the near future, in particular, we would like to tell and share the boilerplate on the laravel-react-bitrix24 api bundle, which we formed in the process. If some moments arouse the interest of the community and they are not able to be disclosed in the framework of comments, we will be happy to share knowledge and experience in new materials.
Source: https://habr.com/ru/post/341726/
All Articles