Transcription
So, let's start again. Good evening. Okay, now I will turn on the presentation and we will begin. Okay, while it's turning on, regarding the sound. Everything is good. Meaning, there are no delays. I hope everything is normal. Uh-huh, thank you. Thank you, Marat. Okay. Okay. Uh-huh. I hope everything is visible. Okay, let's start. The topic of today's session is open, enterprise system architecture design in integrations with 1C. We will look at integration methods, so we will go through them quite quickly, because there are very many of them, but nevertheless, they will constitute a large part, as based on integration methods, we will be able to understand how we will solve a practical task. And we will also try to discuss and solve one of the practical tasks that colleagues are currently solving, how you would build it, based on what we have looked at in the theoretical part. So, let's start. Okay, is it audible, visible, everything is good? Okay, a little about me. I am currently managing the ERP project for the Cicdarge Polymetallic group of companies. I have worked in various positions, both as a developer, an analyst, and a project manager, on all sorts of projects. Currently, my experience is mainly with ERP projects, and not only 1C projects, but also various projects that have to be linked with 1C in the ways we will discuss. Our rules are standard, actively participate, ask questions in the chat. If I see questions, I might not answer them immediately. The webinar recording will be sent to your email, so if any questions arise, ask our colleagues as well. And all questions that arise, we will definitely answer. Webinar route. We will structure our session today as follows. First, we will define the main building blocks of the 1C ecosystem for ourselves. What each of the product lines is responsible for. Mostly to understand the limitations, that is, what we encounter. And then, accordingly, how these products are linked together, meaning we will go through all possible ways. We will define the purpose of certain integration methods and then, accordingly, we will analyze a practical task on integration design, meaning which one to choose, why, how. And we will even see what you would suggest as a system. That is, we will work as architects and understand how much your suggestion might differ from the colleagues' suggestions. So, let's get acquainted a little. Okay, I see all the names. Therefore, two brief questions. Do you have experience working with integrations in 1C? In years, in struggles, with what. And the main goal today, perhaps some kind of basic question, a basic message, meaning what you would like to focus on. So, I see that some people have questions, some people have. Well, besides, yes, nuances. Good, yes, Katerina has a task, 3 years. The goal is to know all integration methods. Introduction from Yes, there is experience, there are nerves. Interesting case of 1C integration 1 Uh-huh. Okay, good. Thank you. Okay, uh-huh, Alexander has a very good task. Uh-huh, I will make a small accent on Kafka and Rapid 1C. But again, look, there are quite a lot of integrations. We will go a little from the basics, somewhere we will skip simple things, somewhere we will focus, in particular, on moments related to the integration of 1C with 1C and especially, yes, the integration of 1C and non-1C applications with each other. Okay, Alexey about the 1C bus. Yes, I will briefly mention that too. Okay, for the boat, how to organize data transfer from server to client without executing interaction systems. Okay, understood, thank you. First, a little about our school, and then we will move on to the main topic. Regarding the school, we create author's courses for IT specialists of various levels, from juniors to leads. Our course is closer to leads, as there are quite a lot of practical assignments, and the entry threshold, at least understanding basic integrations between 1C, should be there. We consider them, rather, in an applied variant. The program is developed based on requests from top companies to candidates, and also to their own employees, meaning, what the market currently demands. The school has an educational license, a diploma of advanced training and retraining is issued. And also, there is an agreement with 1C. Accordingly, it also issues one of the training in a live webinar format. All recordings are saved in the personal account and are given forever, meaning the entire course is stored. There are no restrictions, as some schools have. We provide extended feedback from each teacher on their assignment and session. We update the training program for each launch, as technologies are constantly growing and changing. And accordingly, yes, we adapt to what is happening, so something in technologies can change every six months, especially with the development of artificial intelligence. And you can ask questions to colleagues, including our teachers. And the project you complete will help expand someone's portfolio, someone will simply work with their projects, yes, with the technologies that we don't encounter in normal work. For example, as was the question with Kafka. The courses are mainly IT-related, it's programming, architecture, infrastructure, security, data science, but there is also management, analytics, analysis, and of course, testing is one of them. And let's move on directly to the topic of our sessions. This is architecture design, in integration with 1C. And before we proceed, let's set goals. We will talk about the role of integration in the 1C ecosystem. We will get an idea of integration methods. We will try to cover the most significant ones. If some are very simple, we will briefly mention them, and will not dwell on them too much. I will also talk a little about Rapid, Kafka, and the bus. And our goal at the end of the session is to determine the architectural approach. A classic integration task, yes, we will discuss it at the end. And the goal is for us not to drown in the implementation issues of many applications that integrate with each other. And for a start, yes, how do you, mixed integrations in 1C, I think many of you may have it look like this, but plus or minus, yes, I think this picture, it even describes a fairly simple integration variant of what is actually happening in companies now. There are public systems, all sorts of tender platforms. There are some of our offices, yes, including now, microservices are used in companies. Perhaps some of you are already using them and have encountered Docker and Kubernetes in one way or another, and we also have to learn these things, understand them, yes, and some even learn to install them, deploy them, and work with them. In particular, one of the applications for microservices is precisely for data bus integration, when separate clusters are responsible for message exchange, so if our bus fails, then all this beauty, through which the exchange happens, can also crash if it goes through the bus. Well, here we have it because the integrations are spaghetti, but I think many of you can name examples when, well, it's also faster, for example, integration between typical 1C is done standardly, without using a bus. They don't take place for atypical cases. Nevertheless. Let's move on. And first, let's define the place and role of each product. And, in fact, these are the first origins of our integration. And then we will proceed to look at the typical set of applications in back office and what methods we will use to link all this. So, here we have listed only the main products, but even with them, a sufficiently large question arises, what to use for what, when, at what moment. That is, if we take, yes, each system separately, well, with the exception of specialized products like ZUP, then, well, and probably UT, all other products allow to fully cover the economic activity of the enterprise in one way or another. But nevertheless, these are our main building blocks, yes, from which 1C infrastructure is currently built. We are not talking about dozens or hundreds of industry solutions, but at least we need to understand the basics, where everything comes from and how it is built. And here it is very important what to take. That is, we have three products that grow out of ERP, yes, these are UT and ZUP, yes, that is, ZUP Prof. That is, accordingly, these four products interact with each other architecturally without problems and connect, yes, with 1C document management. In this part, of course, 1C accounting, which historically developed as a separate product, stands out not very well. And in exceptional cases, we connect it to the general contour, as its inclusion does not always simplify our lives. Dmitry, I see your question. We will get to this question a little later, yes, we will definitely discuss it. So, and in order for us to, as they say, to challenge ourselves, let's take a typical back office, yes, and the main IT systems that are present in our office. We have the ERP class systems level, meaning it can be one system, or a complex of systems that we listed above. This can all be 1C ERP, well, except for accounting, everything else can be called ERP and work in integration with each other. Accordingly, ERP class systems are responsible for all this activity. In addition to this, in the back office, yes, these are all sorts of BI reporting analysis systems. These are external document management systems with which we interact. These are electronic trading platforms, client banks. That is, accordingly, our task expands, and the methods of interaction are also different, meaning these are different integrations. And in addition to this, yes, we have, real documents, primary documents, where they still exist. Now, many enterprises, and here the leaders are all sorts of military-industrial complex, are switching to completely paperless document flow. And our differences in TCM systems, interaction with external counterparties are also through some system of legally significant document flow, or through an ADI system. And plus or minus, if we take a non-specific enterprise, yes, we can say that this applies universally, practically to any company, a typical one in Russia. Just a minute. And now let's take the building blocks. We need to link all this together. And first, a moment. Okay, a moment. This is the screen output. Now. Okay. Now, one minute. First, we will talk about the basics, about the foundation, yes, from which, in principle, integrations in 1C systems begin. Okay. Okay. Okay, yes, I see everything now. No. We need to swap the screens. Okay, now we'll do it. Okay, just a minute. Okay, okay, now, one second, I'll turn off the demonstration for a minute. Okay. Okay, everything. Okay, sorry. Okay, okay, okay. Okay. Okay, well, first we'll talk a little about the basics, and, I think, for those who work with integration to a lesser extent, we'll start with the role of exchange plans in our integrations. Well, what an exchange plan is, we won't dwell on it too much here. Meaning, I think, based on experience, everyone is quite experienced. The purpose of an exchange plan in integrations is to define the composition of data that will be exchanged. And in cases where it is necessary, although architects have been trying to avoid this lately, it is the use of the RDP mechanism. Reasons, well, again, due to specifics, due to extra information. Later, when we discuss other integration methods, we will discuss what RDP changes for us. What is implemented through exchange? Well, first, it's RDP for those who still use them. Then, the most important moment that we need is change registration. Here, I think, it's not necessary to comment much. Well, I think everyone is familiar with exchange plans. If someone is not familiar, put a minus. Well, I think, well, it's clear. For those who have encountered exchange issues at least once. And the next, yes, moment, the message infrastructure, yes, for exchange plans, formed for those cases, yes, when we use 1C. Okay. And now, regarding the configurator, yes, well, again, here, for most of you, it's familiar. No minus signs are visible. So everyone is familiar. We set up the exchange plan, what will be exchanged. And in the case, again, how everyone builds their architectural solution here, they encounter that often a full exchange plan is chosen, universal nodes are created in it, and they select what not to register. And, accordingly, in this way, yes, we have such a universal exchange plan for all cases, yes, for all sorts of sources, so as not to create exchange plans for each check. So, in principle, this option is also used. Well, here, I think someone has a different approach. I like both options. Yes, but again, if we look at the typical configuration, they are now trying to minimize the number of exchange plans and use the universal exchange format. Auto-registration is changed to rules, they set it. Accordingly, if registration is manual or by code, then a prohibition, again, in most cases, it is recommended to set a prohibition, so that it is possible to flexibly determine, if necessary, whether we need to exchange something or not. Non-1C systems have peculiarities with data exchange. I think those who have encountered this at least once can even write their impressions in the chat. How to register, everything is clear, yes. Those who have figured out the code, accordingly, message numbers are created. All this is stored in several tables of changes. Meaning, what object we will collect, for which node the exchange is registered, meaning what and message numbers. So here, in principle, regardless of which system we are building interaction with, export from 1C to it goes through an exchange plan. Although, of course, there are colleagues who are still trying to use it, constantly exporting everything. Well, I hope there will be fewer such people over time, or they will disappear somewhere, because such comrades create a very large load on the systems when they use the mechanism of exporting only changed objects. And the most standard application of exchange plans is typical synchronization. for exchanges between typical solutions, yes, meaning data from payroll, accounting, identical configurations, meaning here everything is built on exchange plans and message exchange mechanisms. And here's the next step, which we will also need later, is the method of implementing data exchange. We have data exchange using typical exchange rules, or KD21 and Enterprise data, or conversion data three. Plus, well, conditionally, we consider RDP, export between identical configurations. Accordingly, with the help of exchange rules, KD2 is used, when we have rules for export and import, and we can have quite complex conversion, or perhaps someone has already encountered such terminology as EL transformation, extract transform load, meaning if we talk about it, then for us, transform is primarily important. When we transform the data exported from 1C so that they are successfully processed by the receiving system. Meaning, accordingly, the EL is replaced by such, well, it's not EL, it's a kind of calculation. We write it directly in Okay. Okay, I see. Thank you. The enterprise data format. About 70 objects, maybe a little more now, are exchanged in this format. The structure is clearly defined, accordingly, the objects are already described in advance, yes, business rules, and typical solutions, accordingly, can exchange, yes, using a universal format. We already have a description of the format in DTO packages, which are schemas of our XML files. Accordingly, we do not need to describe any transformation. We are already using this format, the exchange format, we just load the message into the bus. And there, regardless of who the message is intended for, well, for example, what it can be, employees from ZUP are read by the ERP system, and Trade Management, and some other systems, and even non-1C systems, which can also be configured to read the universal format. That is, accordingly, we just register the necessary system as a recipient, and that's it. Meaning, the task is solved. The rules are described in the general module. Conversion 3.0 is used. And, accordingly, the third version does not replace the second for some complex cases, especially if we take such a very difficult moment now, the replacements that 1C is trying to perform now. This is the transition of SPP to ERP. If someone has encountered this problem, yes, you can put a couple of pluses. This is probably a more epic task now than the transition from version seven to version eight. Okay, Marat is asking a question now: what non-1C systems understand the universal format? Look. For a non-1C system to understand the universal format, we simply write a parser on its side according to the same rules as for the system. Just read these formats. And in particular, in our last two projects, one of them was the Oracle Domino system. It read the universal format. Yes, it doesn't understand it out of the box, of course. Yes, you can teach it. Now we will return to the question that colleagues asked, about artificial intelligence. Yes, something can already help us write handlers for parsing the universal format, yes, into some format, systems from ancient times, yes, meaning you can get it and, in principle, come up with handlers for parsing the universal format and loading it into the required format based on the database. Well, yes, you'll have to teach them a little to come up with such scripts. But out of the box, yes, they are all supported. Fundamental differences that we will need in the future are that in enterprise data, the exchange happens, in fact, not between configurations, but between configurations and a universal format. That is, in fact, it is our intermediary. That is, we transform everything strictly into its format and read it in the same format. Advantage: you don't need to know anything about the structure of the receiving party. We just throw it out, and that's it. And any system that we teach to support the universal format can read it. Correction of export-import algorithm only when the format version changes. We have gone through this experience. The format version changed. Because ERP is constantly developing, and the receiving system, as Marat writes, yes, we taught it to read everything in the new format, as there were some new fields. For example, what is now some data transfer for labeling, our favorite honest sign, and so on, yes, and mass documents that were not used for this before. We attach messages to it, so that it also goes to the honest sign. Conversion rules do not need to be described, yes, processes are standardized. And accounting system, yes, is implemented more simply. Disadvantages. Well, here there are two unrelated stages. Data export, import, meaning separate conversion rules are limited by the composition of transmitted data, and there must be corresponding functionality to support the formation mechanisms, but this is for 1C configurations. And again, the limitation is progress, meaning the support period for the format version changes, pressure comes, and everything has to be rewritten from scratch again. Well, so there are pros, there are cons, but nevertheless, we understand that there are certain limitations. And in particular, yes, typical synchronizations between systems based on the ERP architecture, yes, they use the universal enterprise data format, meaning the synchronization scenario is configured, described, and then the export follows. A little about RDP, and about nuances. What do we need RDP for, if someone still uses them, as it was historically proposed for geographically distributed systems, for database cloning. And it allows us to transfer configuration changes and data changes. What is the disadvantage? Well, this is also its advantage, yes, it is the impossibility in case of minimal configuration changes. Marat, yes, and I will talk about this now, that the question is: does many people still use RDP? It seems there is a trend to move away from it. Yes, they are moving away from RDP. Now, as I am commenting, the latest architectural solution that colleagues from Otkoy are implementing is to use enterprise data instead of RDP and exchange without RDP. That is, even if data replication is needed, it is simpler, well, as it is conventionally simpler, to finish enterprise data and run everything through it, rather than using RDP. Because in case of the slightest changes in the main database, the exchange will not break, there will be no delays in message transmission, meaning we will not have a downtime window. Well, ideally, yes, to abandon such exchanges. What might we need this for? Well, a likeness. A practical case that is also from project practice, for example, we plan to buy a new company and upload its data to us. Well, or a more, yes, a real one, to sell. We need a company and, accordingly, to transfer the information base only for it to new owners. I think many of you have encountered terabyte transfers, exchange rules, data deletion. One way or another, this can take a colossal amount of time. Simple copying, data export with a filter, yes, one of the solutions that was proposed offhand, let's use RDP and export data with a filter by organization. This can take days. So, accordingly, exchange without RDP, such a database copy can be faster. Well, even some logic is built on this mechanism. For example, they do inter-exchange between ZUPs, yes, meaning payroll is calculated in one, and exported to another centralized ZUP, which consolidates all data. But again, this is without RDP, universal format. Reasons for use. And in particular, yes, many of them are no longer needed for us. A geographically distributed system can be conditional, but it is solved simply by locating the database on the same server and correctly configuring RLS. One of the reasons 5 years ago, oh, how many, not even 5, 10 years ago, was poor communication channels. Now the problem is solved even in remote villages. We have fiber optics, and accordingly, through it, we switch directly to the centralized hosting server. Understanding that now the data volumes that we need for the enterprise to function are quite large, and the PPH communication channel will not allow the enterprise to grow in the future, as, for example, the use of artificial intelligence or something else requires, well, such good data transmission between systems. And it is not always possible to place a powerful server room at each of our production sites for all this to function. Horizontal scaling, I mentioned this. This is about buying, selling enterprises. Monolithic configuration, sites should work quickly, this is solved by enterprise data and separating configurations into a separate system. RLS analog for those who don't know how to cook. And switching to DBMS or platform. By the way, the sixth point. In fact, yes, this is an analog of integration. This is for those who may have encountered it, again, I ask you to put a plus. This is updating via a copy. Has anyone done it? Was it successful? Please also say. Yes, with SBU. Because one of the popular tasks, which is even asked in interviews, is, we want to minimize downtime. We work 24x7, we cannot interrupt. And what are the ways of updating? One of the questions with an asterisk, yes, which Eugene, yes, Eugene, these mechanisms, yes, Eugene? One of the questions that is asked secretly to a candidate is, we have a system that requires an update, and we must work 24x7. Our window is 15 minutes. We understand that the update will not be installed. What methods will you use? And one of these options that they try is, are there DBMS tools that allow such replication? And not many candidates are afraid to show some kind of incompetence, to say: "Yes, I haven't encountered it or something else." Or they try not to say directly that replication for 1C systems cannot be done using DBMS tools. That is, if one of the databases undergoes restructuring due to sufficiently complex mechanisms, only updating via a copy allows us to make such transitions. Therefore, here, you may encounter something like this. Well, here is the RDP structure. And let's go through again. We understand that it is already dying. I hope so, because it is already a bit irrelevant for us, we use different systems, but not such links, this is if anything, I will ask you about them. Okay, now let's go to the next one. Okay, let's go to the simplest option. This is exchange. between non-1C systems. And let's look at four formats, yes. Meaning text, XML, JSON, and again, let's go through them briefly. All, thank you, missed. Okay. I think absolutely all of you, when dealing with text exchange, I think even Gigachat can now generate code normally. Not to mention the 1C partner for reading and writing text documents.
For 1C, uh, and under, probably, it will even work. Well, for what it can be used, for the same exchange, for example, some kind of banking for loading, parsing statements, it can still be used in some clients that have not switched to XML. XML again, yes, a familiar way of exchange for you, yes, that is, accordingly, a structured object is used, yes, we also have standard methods. Another option is Excel. Someone still continues to prepare COM, uh, this is a pain. I hope there will be none left, but old configurations remain. Well, there are old applications, uh, and quite expensive, uh, including Western systems, to which you can connect only in this way. Uh, yes, Lena, Linux and they don't get along. That's why I say that for the sake of, uh, what you should remember about the presence of COM, we can refuse it. Maybe there is some exotic system, in which constructors still work, some kind of, uh, geological system or some kind of design software, we won't be able to connect. So, uh, well, uh, if we talk specifically about Excel, yes, a little separately, uh, that reading, uh, from Excel through it is quite sad, gloomy. Uh-huh. So. And type conversion, yes, it's not cheerful. The question is about extraction. I'll comment now. So. So, the second way is reading an object through a tabular document. What it is used for, I'll tell you now. That is, this is like reading through a tabular document, there is a nuance, it reads one sheet. Well, and the third option is reading. If it's Excel, then it reads a set of XML archives, respectively, also. Uh, what is it used for and why are we talking about integrations? Uh, by integrations, this is not necessarily a direct connection, this also includes all sorts of possible automations to this day. Uh, well, if, for example, we are talking about working with suppliers, uh, linking their systems and our software, there is not always such an opportunity. Their systems can be completely their version of 1C, like a distribution or something completely their own or thrown together on the fly, they prepare it in a certain format. Uh, structuring in Excel is the easiest, well, or there, Open Office, the required file, go to our supplier portal and upload it to us. Well, respectively, our system will parse and check it. Uh, instead of, yes, forcing the supplier to prepare files in the format we need and so on. Well, if we are not some kind of supplier, like, oh, not a supplier, a buyer, like City hypermarket, then some Pyaterochka, where the supplier is forced to prepare everything in modern formats and issue it not in Excel, but in strictly, uh, our formats, in the same JSON. And here's how Evgeny comments, yes, Marat, that you can refuse COM and use TDOG saving to Excel, yes, that is, TabDoc can be used for copy-paste, in particular, buyers often use it. By the way, about the same Excel. It's not for nothing that they now made the ability to copy-paste directly, uh, in the same 1C: Holding Management, from tables, because economists still sit in Excel, they go there, uh, they do calculations. Further, this can go into a business modeling system. This is, in particular, one of the tasks that I am currently working on. Uh, complex calculations can take place there, and into the final file, again, so as not to write an integration into TRP. It is issued in the form of an Excel file, which we also copy and paste into ERP, and we create a plan for the month there. Well, as a variant, this is our integration, it seems, but integration, not integration, yes, in essence, yes, it's not a question of automation of integration, manual exchange in the case when writing automatic integration, uh, is expensive, well, so to speak, a budget issue. Everything can be automated. format, yes, if, accordingly, we have a budget, if not, yes, yes, there are tasks. The next format, already more friendly to us, is JSON. Very light, unlike XML, contains a minimum of unnecessary characters. Well, it's clear that there is a moment about the structure. Well, small questions, yes, which format is most convenient for exchange between 1C, for cross-platform, and what would you choose, XML or JSON. Well, why? Let's think about it. So. colleagues. So, well, let's say between 1C databases, that is, uh, uh, that is, some kind of XML or the second cross-platform exchange, that and the third XML or JSON. JSON is lighter. Uh, but the exchange of 1C blue 1C. Uh, XML for 1C. Uh, why? Are there any arguments? Well, Lena, the format should be such that the programmer knows how to work with. Well, by the way, uh, on one of the projects, we encountered that the exchange between Trade Management and 1C Accounting went through, uh, standard systems through JSON, custom-made. Well, and here's how it is, yes, it happens. So, XML when used for XSD, look. Well, data is more popular for exchange in the database gradually. Uh, and also from Denis, yes. COM. Well, because it's convenient, because it's nearby. Yes, the transition to JSON, yes, this is good. That is, still, uh, uh, not a direct connection, yes, this is asynchronous exchange, this is still our everything. Plus JSON on top of everything else. Slav so. ZTO XML JSON JSON always, well, plus or minus here, yes, it depends on the projects. Well, I had to do integration between NFRF and BP, and BPZ, BP Kazakhstan, it turns out. JSON solution. Uh, all right. Tele Kazakhstan. Well, yes. So here everything is determined by the context. Thank you. So, and a little about the theses. Again, this is a reference for us, uh, reading an Excel file, yes, we've already discussed it. XML JSON JSON structure is simpler for perception and for cross-platform, oh, for cross-system interactions, not cross-platform. So JSON is lighter, you can throw it in by hand, and the system will even read it, and testing is easier. The tooling is simpler, the code is shorter, uh, but, uh, XML has an advantage with the use of, yes, respectively, the factory. And we have a much larger number of objects. Plus typing, uh, that is, the ability to work with references without, uh, additional efforts that are necessary when transferring through JSON. A little about external data sources, which are forgotten, but again, there are tasks that are solved with their use much faster. Uh, we can also consider them as integration. Working with databases not based on 1C Enterprise, and, accordingly, we can use this information within the solution as if it were part of the database. Uh, it can be stored in any system, yes, on any server, accordingly, using the query language capabilities. But, uh, there is a limitation, it's the DBC driver that is used. How it is built. I think some of you have already used this. Uh, each table is an independent configuration object, a set of fields. And we make a query, yes, accordingly, by the names, uh, of the table we are accessing. So, has anyone worked with external data sources and maybe can provide some example? So, what was it needed for? So, uh. Practice, TRP integrations, Tatiana. Mm. So, why external sources? I think only if you really need to write to another database. So. Uh-huh. Well, there are large volumes to transfer from BTRacle once. Receiving fine data from BBBTDD. Uh-huh. So, Tatiana, uh, look, uh, regarding the question of why we need external data sources. One of such project cases is the transition from a non-1C database to 1C. At the same time, in the non-1C database, we store, uh, large data tables, which we must rely on for some time until 1C accumulates this data itself. In particular, this is accounts receivable for the historical period, on which we have rules for shipping to the client or not. That is, there is a depth of overdue by legal entities. This is information about some kind of historical commodity turnover, which again makes no sense to convert into the 1C structure and load into tables, if we need this, again, for some operations, that is, for checking returns. So, this is from practice, we used it for the transition from a non-1C platform to a 1C one. Another option, uh, as colleagues are writing, uh, if we have something large like a system, yes, and there is no point in integrating this system directly into 1C, uh, what are such tasks? Uh, uh, pricing, uh, a very complex price determination mechanism. Uh, according to the price, if we had left all this, it would have run very slowly. Therefore, all pricing was done in a separate database, uh, and run there, well, a separate team worked on it. And we only took the price table, oriented ourselves to it, and then deleted old documents from 1C, did not store price history. Uh-huh. Yes. Well, colleagues are also giving different examples. Reading the structure of external data, fields manually. Yes, this was a problem from, mm, as nuances that, yes, uh, uh, were earlier, that it was necessary, yes, these fields were renamed and everything broke. Uh, and here Marat also transitions from a non-1C system. Well, the most typical case, yes, typed Excel document loading as scanned. Well, if Excel is strictly defined, it is also a standard plus or minus, uh, storing files not directly in the 1C database, but in an external database. By the way, Stanislav, for your case, well, if it's a standard system, we are still using the 1C Document Management mechanisms. Well, again, it's possible there. And we store all files directly in it, and it is already in an external file mirror. Accordingly, all this runs separately for us. Well, again, it depends on the tasks. Self-made set, yes, here Tatiana, so external sources are faster than BD queries. Uh, well, look, Tatiana, it turns out that we don't need to keep the DBC connection open all the time. That is, it can be separate, but simply for each request, it is necessary to specify this. Connecting to the database, connecting DBC, and so on. Here we have a standardized connection and load, that is, the number of connections to this external database is less. So, well, checks are faster than BD queries. Uh, if you use ADBC in both cases, it's practically the same. That is, I haven't encountered such a problem here. Well, let's move on a little. So, well, uh, connection, this is an open connection, yes? That is, it connects there and that's it. That is, if the database goes down through an external source, then in the code where it was, uh, accessing it, then we will have problems. So, well, about COM, we've already discussed it, about our outdated method, so we won't dwell on it too much for projects with Legacy, but nevertheless, it's still alive and for some time, I think, it will be with us for quite a long time. Well, and here's a classic application, yes, there's a scanner base for documents via COM connection, it goes there and takes employee photos, and this might not even be a 1C system. Well, and accordingly, P stores personal data. So, next. We are now approaching the Rabbit with Kafka. Well, here we will only go through the differences. First, it's web services and HTTP services. Uh, a favorite question in interviews, yes, what is SOAP, what is REST, yes? That is, one of them is a protocol, and the second is an architectural style. Well, that's like comparing apples with oranges, so SOAP is a protocol, in particular SOAP, well, colleagues are writing with ATS, we used systems for working with requests, interaction, yes, they use XML format. Well, and REST is simply an architectural approach in which we use, uh, various data formats. Uh, and, accordingly, we can use SP in requests, yes, with, uh, with, with an architectural style. Well, and for example, yes, top services can be interaction between a repository database and a client database, as a web service, as an HTTP service, and a third option is through ODATA. For XDTO or for a web service, now, uh, for those who have already worked with this, it is necessary to define the structure in advance, type the package, specify strictly what data will be received, operation handlers, yes, accordingly, publish all this as a web service and then, uh, accordingly, it will be registered, uh, on IIS or Apache. After publication, information about it will appear. Uh, and at the end, we can read the description of the format that the service supports. Accordingly, the data will be strictly converted to this form. And by accessing it, yes, we can interact with our system. That is, by request, yes, we read the package, we read the system data. Well, and the link, respectively, contains an XML file, yes, already typed with a specific XDTO schema. That is, here we briefly remember for ourselves or for those who haven't worked with it. So, if there's a question about web services, again, in which cases will you use what, web services are typed access to data. Well, and accordingly, quite strict control over what we are doing. HTTP services have a more flexible structure. Often, uh, colleagues, uh, do such, uh, well, let's say, not a very good thing, as a universal HTTP service that does everything, for reading, for writing, or so on. But this is a very big security hole, so I don't recommend doing that. Such super-universal, but in certain cases, when we want to work with databases for some time in test mode or at the stages of launching new systems, such universal HTTP services solve a large number of tasks, including, uh, data transfer, requests for some, uh, structures that were forgotten during construction. That is, this is our insurance, but it's better not to create universal HTTP services that are responsible for everything, as everything can break, as we can also move the handler itself to an external file, essentially storing everything there in a text editor. So, now, Tatiana, I see your question. So. What volume can be processed through services? The entire implementation for a large organization. How to get it for reconciliation? By the way, if we take the same HTTP service, it depends on what kind of large organization, how much? Millions of documents. And how much do we have? Hundreds of thousands, uh, well, millions, well, not in one package, but in separate packages, using the mechanism, uh, of exchange plans through web services, yes, you can load. There are no questions here, but we, uh, how to say, it's not designed for this. That is, I don't really recommend running documents through an HTTP service, as it is more intended for such online integrations, when we need to get a piece quickly for certain tasks, for example, to generate some report based on current data, or, for example, to get information about current, uh, debt from ZUP, or something else. That is, some kind of local task. That is, if we need to run in a stream, this will be our next piece. This is still about running using either an exchange plan, well, that is, exporting through a file, uh, or we use a bus. Well, the bus, accordingly, can use the HTTP service as a transport and at the same time guarantees us delivery. This is exactly what colleagues asked about Kafka at the beginning. Uh, we'll return to it a little bit at the end, uh, not return, in the sense, we'll move to it at the end, we'll discuss it. That is, it depends on what is required. Well, if it's on a regular basis, it's better to set up, uh, well, accordingly, something similar, there, that is, one of the options is RabbitMQ, and run this implementation in several threads. Uh, we did that, uh, millions of documents, implementation passes without problems. Well, and RabbitMQ, accordingly, uses as, uh, transport, accordingly, HTP service. So, by requests, yes, that is, the main methods, I think, those who have worked with them already. That is, there is get, yes, the rest are used much less often. Uh, again, in practice, most often we use a couple of methods, that is, getting data without any transformation. Uh, well, yes, yes, yes, post, post, post, that is, send for processing and receive. Uh, and this, uh, patch is more of an exotic thing. Uh, well, again, depending on the implementation. It depends on the architect, on yours, how he defines everything. Maybe for strict. Yes, yes, you can. Uh, in WB, uh, WB is Wildberries, accordingly, creatives. Uh, well, apparently, yes, maybe they can demand it. So, HTTP service requests. Well, here it's clear. That is, we knock, we read, yes, here's the file, yes, which it gives us in a certain format, the answer. Most often it will be JSON. Uh, we can check HTTP services, uh, using popular utilities, uh, such as Postman. Uh, yes, here's how Elena said that a web service is an API or as the term is also used, a handle. That is, to pull a handle is to access our system through a web service with Postman and, accordingly, get everything from there. So, now Pavel, minimum integration, AТС post, I don't want to get stuck on the client, how can I transfer events, server events, client events, server response, how to do it, so that the system, well, what's the complexity in HTTP service, Pavel, classic? It's just that the interaction system is more for acceleration, for simplification. We use the interaction system in our projects only if we can convince the customer very, very strongly. Uh, uh-huh, here's a good task. We need feedback from the server to the client. That is, it's a question-answer. So, let's discuss now. So, about OData. A little bit about it. So, standard OData interface. Accordingly, this is also part of the REST interface, through which the platform automatically forms. It's enough to publish this interface. And, accordingly, external applications, such as some BI, can interact with our database using HTTP requests. Uh, but there is also a trap, uh, in our OData now. That is, yes, it's easy, yes, it's published, but what is the disadvantage of OData? Uh, there is, maybe someone has encountered it. Uh, well, first, yes, it's read-only. So, uh, uh, so. Yes. Well, one is that you need to define types, and the second, uh, a serious disadvantage of OData. It returns an excessive number of fields. That is, we take an object and it returns everything that is in the object. That is, as a result, if we need, for example, to get only the product name from the nomenclature catalog, we are returned 150 attributes in the package. As a result, we have an overloaded message. Uh, for quick hypothesis testing, yes, okay. Uh, for any productive things, OData will be a rather heavy option. But it's fast, universal. So, Marat, what did you build with OData last time? Uh, classic PowerBI, we just connected, well, before 1C Analytics appeared. Now, uh, we practically don't use OData. Uh, before that, we used OData for Power BI, so as not to run around, not go to the database every time for new tables, not to describe them. We just put the maximum number of objects and documents into the OData interface, uh, in the description, and received them through it. This is one option. The second option, uh, we had similar systems, that is, a source database, a receiver. Through OData, we took the structure, a ready-made table. Well, such a thing for life requests. Well, and Kafka, in part, replaced the need to study Power BI and its OData, accordingly, typing of fields, and, I hope, partially, yes, it can provide adequate dashboards. Uh, but not entirely, of course, in the BI system, yes. So, and by theses, what do we have? Uh, OData is access to 1C data from non-1C systems through HTTP, uh, developers don't need to be heavily involved, yes, accordingly, through OData, some analysts can access it. Uh, Pavel, here's a question about security. So, HTTP services are faster and lighter than web. But due to the strict control and typing of web services, accordingly, we guarantee that we will have the necessary types. Uh, in the case of HTTP services, as many have encountered, we need to write all checks, yes. Uh, here the question is not about TLS, but about business logic. Uh, a web service will not let crooked data through at the type level, but in HTTP, you can pass anything. And, accordingly, everything depends on how well the handler, the developer, describes and processes data types on the service side. So, about OData, you can't. By the way, here's another point. Complex queries cannot be obtained. By the way, a set of data from joining two registers. Well, well, well, well, what one analyst can do, OData cannot. That is, as a result, uh, we took the register separately, the document separately, and in Power BI, we did the join. It was really sad and miserable. That is, accordingly, some query that is now done by one analyst, you had to copy, essentially duplicate the query mechanisms, uh, that we had implemented on the 1C side. So. And now. And now, before we move on to RabbitMQ and Kafka, just a second. So. So, so, so. So, well, let's have a small task for reflection, and with it, we'll discuss the architectural solution. So, what do we have at the input? Maybe someone has already solved something similar, but here the question is also quite interesting. Uh, we have an ERP system in the company, uh, in which purchase requisitions are created. Now they are manually processed by buyers, uh, accordingly, Excel files are posted on the trading platform, Excel files are uploaded, accordingly, it is determined manually here, with whom the contract will be concluded, and here the contract comes to the system, yes, accordingly, from any document management system. Uh, contracts and suppliers also go. in manual mode, yes, accordingly, draft contracts and analytical data are absent. Uh, what we would like to determine is, first of all, what can be used as a CRM system? Uh, what options would you choose? Now we'll move a little further. And methods of exchange, uh, with the trading platform. Uh, if it is an external, uh, essentially, SaaS solution, that is, we cannot install it, uh, but we would like to somehow receive, synchronize data from there. What if we decide to change this platform? That's one. Secondly, uh, somehow automate the work of our colleagues. And what does the market offer us? They offer us two options. Either, uh, take some 1C solution, or write everything from scratch. So, so, just a second. So, increasing here. So, increasing here doesn't work. So, the process itself is visible. So, let's do it this way. So, we have, well, these systems. The process was described by the user in this way. So, there is the formation of needs, yes, this is formed on the side of our internal system. Then all this is done manually by interacting with the B2B platform. Uh, and we would like, yes, to determine here which system to install, 1C or not 1C, and some, uh, maybe arguments from you, so that you would install it here. Uh, and, accordingly, determine which of the integration methods you would use, yes, for these interconnections. Well, not every, yes, of the methods. Well, that is, what would we apply here? I think how we will check, how familiar we are. So, classic. Uh, uh. So, Elena, Ekaterina, yes, have encountered a similar task. Uh, Stanislav, well, Stanislav has the most powerful solution, ERP, but it's also the most expensive solution. This is if we do it from scratch, yes, we throw out this thing and wrap all this up. And then no integrations need to be done, but only interact with the external platform, yes, through web services, yes, in principle. Uh, so, yes, so ERP is closer. Uh, would anyone agree that this system would be completely non-1C, but custom-made? Because there are companies that come and say, "We will write it from scratch for you, it will be a unique offer for you." At the same time, the volume of our purchases is not that large. There are 100 open purchases in progress daily, there are 20 people working. So, and they offer us to write the system from scratch. Are there any arguments? Well, and again, so, here, so, this is a question of understanding, how to say, our environment in general. Oh, Pavel, so in an empty database, your own control and contract module. M, well, so, look, there are other nuances. This thing, uh, that is at the top. That is, users are used to it and don't want to give it up. This is in terms of restrictions. Yes, yes. Yes. Well, if the product is written, agreed with the contractors, a good question. So, implementing ERP can be cheaper in the end. Actually, a simple solution based on BSP. Well, a good option. So. Are there any other ideas? So, support. Uh, so. Uh, look, colleagues, uh, uh, here, since we are talking about architecture, uh, uh, you need to understand, first of all, what systems we have here. Well, let's say, uh, here we now understand 1C PP, that rewriting it can cost hundreds of millions of rubles. Well, so, replacing this solution here will be problematic. Uh, a very important moment, the team on our side, that is, what resources besides the configuration we have, that is, we don't forget, yes, that any writing of a configuration from scratch, uh, and even more so not based on 1C, leads to the fact that our team will not be able to support and develop this solution, because not
We forget that we have a team, you see, 1S, yes, and we have, accordingly, 1S developers. There are, of course, those who know 1S, Python, something else, but you understand yourself that there can be quite complex questions here. So. Well, and let's now, as it were, talk a little about solving this case. That is, how to solve it, yes, as an option, 1S Holding Management is currently being discussed, but at the same time, we are not calling it 1S Holding Management, but rather giving freedom. And what Pavel is writing. We give freedom to offer us something customized, but at the same time meeting the requirements of the "muk", that is, perhaps additional refinement to the "ukha". Further, accordingly, exchange with the tender platform, well, we do it via API, yes, and we take as much data as possible from there into our standard system. Well, here, as colleagues write, it will be necessary to customize it a bit, yes, so that, accordingly, some objects can be integrated. But we will use most of the processes on the 1S side. Nevertheless, colleagues perform part of the tasks on the tender platform side. Well, and what they do there, how they choose the winner, something else, should fly to us, well, and, accordingly, synchronize, yes. Here are the deadlines, the amount, yes, the best standard solution. Therefore, one of the options that we have actually put into work is that there should be a unified solution that synchronizes with the external platform via HTTP services. Well, that is, via API. Accordingly, the contractor who is supposed to show us this solution must have experience interacting with the tender platform, yes, specified by us, ideally. Well, if it's any other tender platform, then, well, integration experience with, well, or 1C configuration with the tender platform and an understanding of how this process can be built in the system. Well, and plus, accordingly, these integrations that we have here are the export of centralized NC, this is, accordingly, the creation of a counterparty, when the contractor is determined. Here is the conclusion of the contract. A very important stage, as all users work with approvals using 1C document management. So. Uh-huh. Yes, we are glad. So, well, if anything, you can watch it in the recording. Uh-huh. Thank you. So, and approval of primary documents. Well, this block, by the way, does anyone have any idea what this might be and how difficult the implementation of this block might be for us? That is, contract execution. Well, doesn't something seem suspicious to you here with an asterisk? Well, here is B2B center for procurement. Elena, well, look, our deal goes through several stages. Well, that is, before we got to the conclusion of the contract, that is, the contract was concluded, it seems like, yes, something went well, don't bother us anymore, yes, and it was passed on. This is the first option. So, execution control, simple, type, task implementation. Yes, Elena, these are acts, and execution is, in fact, when we started the supply according to our contract, and this is already a very complex chain, this is some kind of logistics, tracking movements, to what stage, arrived at the warehouse, did not arrive. That is, here the analyst, if they unfold this process, here under the plus sign, yes, there can be half a screen of diagrams. And therefore, if we want to minimize the system, yes, to solve this problem again, yes, to return to this very statement, then the problem will be solved, and we will have to allocate this piece to a separate project, as this is essentially part of tracking the supply, yes, contract execution is closed by receipt, when what the user wanted arrives at the warehouse. The procurement process is closed, but this block is almost a separate project, and it would be good to allocate it to a separate integration process, as there is also integration with the warehouse system here, with the acceptance of goods into the warehouse. So, sources of contractors. So, mutual settlements, yes, this includes mutual settlements. This is also here. That is, up to this block, we have no money. That is, no one owes anyone anything. Here we just go through everything. Here at the level of applications, the contract is concluded, the registers are closed. That is, everything is fine in this system. If we go out here, then we again have some kind of input before receipts. And, until the receipt is sent to the warehouse, so that the chain is also closed beautifully here, respectively. That is the turnover register, until it arrives. That is, this chain will have to be untangled. And if there are also mutual settlements and so on, then we end up with what colleagues were talking about above, this is the ERP system, and accordingly, quite complex issues related to it. So, check. So, when leasing, everything was implemented, CRM directly made copies of lease supplies. Yes, after the supply chain, it will be implemented in a separate system in the UT. Yes. Elena. Oh, yes, this is already a different task. So, one of the such architects is to decompose what the ERP specialist comes to us with, yes, and, accordingly, break it down into separate projects, into separate tasks, because otherwise we will just get involved in a project that we will definitely not complete. So, why is this here, and this is the approval of the procurement plan. That is, when we formed it, it corresponds to the budget and simply confirm that, yes, we are spending this money on it, yes, from the series, just to confirm that it will be approved. And here, well, this is understandable. That is, the contract that was obtained here, users should not be allowed into this system, this is a duplication of the approval function. This is why we cannot fully use, for example, an external platform. We, accordingly, must implement it in 1C document management, using standard seamless integration. So, here are the integration points, yes, we have our own integration here at each piece. This integration, depending on how our MDM is located here, accordingly, it is best to leave the bus. Now we will talk a little about the bus. One second. And Pavel, based on CRM, contract execution control. Well, yes, with some statuses, but again, contract execution, you need to receive notifications. That is, what about our supply? Has the cargo left, who should mark it? That is, the buyer, accordingly, must go in, yes, submit information about it, or somehow get this information, at what stage, are there intermediate acceptances before our central warehouse, and mark all this chain. So. So, now. So, now I'll switch. So. Uh-huh. Well, let's say so. So that we, we'll go a little over the timing. But we have, the most interesting part is left. So, colleagues, one second. In the beginning, there was a question about buses. About. Now, one second. So, so, so. And Alexander, yes, asked about using Rabbit 1S about the 1S bus. Uh-huh. Exactly, yes? So, we'll go through it a little. So, Dmitry wrote how to interact with another service via DBAS in Linux. via an external component. I will now, Dmitry, colleagues, leave you my Telegram nickname in the chat. Those questions that remain unanswered, you can send them to me on Telegram. Well, about Linux, please duplicate it in Telegram. We may not touch upon them immediately. So. Uh-huh. So, everything. And, accordingly, yes, I will definitely look and answer these questions, as this all concerns integration, and on some topics. Well, in particular, our enterprise architect can also help advise additionally. We will definitely turn to them, as the question is very important for us and we need to solve it. So, let's talk a little about Kafka, and if anyone has encountered Rabbit, then we will also mention it a little. Well, again, let's do it in the context of Kafka, so as not to distract from Rabbit separately, how to say it. So, and what is Kafka? And in particular, why it is not enough on its own? Why did we have products like USB, that is, or enterprise? That is, a broker, what is it? That is, a broker is what is responsible for the transmission and distribution of information to recipients. That is, we export a message, how our Rabbit system works. That is, we export a package and say: "This package is for three recipients." When all three recipients have taken this package, the package is deleted from our Rabbit, and no traces remain. What does USB allow? To store messages and perform one more very important and useful function. Therefore, we will return to it. Well, and the database, this is, accordingly, a storage of recipients and receivers of our messages in integrations. And so, Kafka is a distributed platform. It is probably not used directly in 1C in its pure form so often. And mostly it lies under the hood of other products. Why is it needed in 1C? Well, and when we, accordingly, need to understand it. This is working in diverse environments, when we have a zoo of the entire cloud, Linux, Windows, some MES systems, something else. That is, a very large number of systems, well, MES systems are those that provide data from equipment in real-time about meters, about equipment utilization, respectively, and visualize the functioning of our large plant based on them. The speed of packet transmission via Rabbit or via Kafka in the case of exporting in multiple streams is almost instantaneous and is tens or hundreds of times faster than standard exchange. Stable, reliable, conditionally, I would say, free, as we understand about freeness. This is the knowledge of the architect, the DevOps who understands it. Simplicity, ease, because there is documentation. ChatGPT can help write code to access Kafka and a large functionality. Let's immediately compare these products, their differences and performance, speed, order, priority of message storage. We have size limitations, the third message, relation to the consumer. Now, check. So, uh, performance. Well, it is clear that since nothing is stored in Rabbit and it is taken away, everything is given, there is no need to accumulate anything, so Rabbit works more cheerfully. In terms of speed, they are probably comparable. That is, priority is like this, uh, they did it, but then somehow to pull it out, but it can still fly out. And, by the way, Elena gives a very good point, which we also encounter, even in our bus, which, yes. It has logging, but somehow colleagues still lose, manage to lose messages. The non-1C team loses messages that we send them from 1C. Logging on their side is absent for message processing, so they read the message about reading it. They do not store the package itself that they read, as it was absent in their system as such. They taught their system to work with packages from scratch, well, that is, with data buses. Accordingly, if in 1C we have a message number, yes, well, again, that 1C is usually stored only on the bus, then 1C can also have logging disabled for what we sent, then storage, yes, on Rabbit, as Yeda writes, this is, in principle, also one of the options we used. And in Kafka, our communication is stored, and we can store it for as long as we want. Accordingly, to set priorities in what order to read what. A sore point. When 1C and a non-1C system, a simple one, a counterparty and its folder, for example, or its contract, triggers, the contract flies out earlier because it goes earlier in the distributed stream, and that's it. And if the receiving system is not configured for message storage, for reprocessing erroneous ones, and so on, then we have problems. Accordingly, we have to remember all these things when we work with non-1C systems. They don't all know how to store until there is an owner. Not all architects on the non-1C side understand that we have such an inconsistent package coming, as some imagine, that everything can be built from it, and that it throws objects in separate pieces, even those that are not yet in the database, they only need to store references to objects that do not yet exist. And all this needs to be tracked. Another interesting task is to exchange between 1C and non-1C, or between two 1C systems with diverse data transfer, using either Kafka or Rabbit. Well, interesting tasks can also arise. In most cases, if they don't think on the receiving system side, it crashes, it is installed. Well, we won't go too deep here. The simplest thing, yes, for yourself, if you suddenly want to try, is installation via Docker. That is, if you configure it without Docker, well, you'll have to tinker a bit. Colleagues, we work on this for two sessions in the course to master it, so that it takes off. But nevertheless, yes, this is part of the project. So, one second. And now a piece I wanted about 1C. So, so, so. Kafka Architecture. Considering Kafka, we can, in principle, conditionally consider it as a universal description. Well, in principle, prototypes of buses. That's it. What does Kafka consist of? Kafka consists of a cluster of servers to support processes. Essentially, it's an internal 1C mechanism, where there are terms, yes, topics for organizing messages. And we organized this similarity using Rabbit mechanisms, separately made topics, well, that is, for transmitting separately the counterparty stream, separately the quarter, separately orders, separately prices, and all this to speed up the exchange between databases for transmitting hundreds of thousands of documents in streams. Accordingly, the recording mechanism goes. In such cases, for example, now, Alexander, we will get there. So, here, how to say it, for those who have only worked with 1C, it might be quite difficult. That is, all these terms producers, writers, consumers, well, like that. But it is accepted, unfortunately, there are no separate Russianizers for these. That is, if we immediately learn the 1C bus, then we essentially rise to a higher level. So, these topics go. Well, that is, essentially our packages are divided into parts, accordingly, into pieces. And they are transmitted in pieces through partitions. Accordingly, the message format, there we store in Kafka the message key, some data, a timestamp, compression, and a piece of this partition is added, which is added to our package. So. Well, 1C directly with Kafka components exist, but they are, let's say, free, they turned out to be not very comfortable to use. And direct use of Kafka is justified only in the case, yes, if the receiving system is not configured. So, one minute. In the case, if we don't have configured systems and we still want to simplify our lives, then we should switch to USB class systems. This is to our buses. Now. So. So, now I'll go through the disk. Now for a minute. So. So, now. Uh-huh. So, and let's talk about the bus. So, yes. Alexander's question about the Kafka system. In what cases, now we will discuss it. Both systems do not store successful messages. Unsuccessful ones are accepted by 11 years of start notes and private reading. This message will not be anywhere. Only duplicate from 1C. Mm, ah, yes, so here is the problem that the message will not be there and it has to be duplicated, if this package is not stored somewhere separately, and information about reading is not received on the receiver side. By the way, yes, a disaster, a disaster, and the strength of Rabbit is that the speed is high, because it doesn't give anything back, it doesn't transmit information about a successful package. And in the case of using Kafka, or buses, we can get a response, and in the case of using Rabbit, yes, or some kind of custom bus, in which successful reading is mandatory, then the message can be deleted, and that's it, and then we don't understand what happened to it. So, now about the bus. A normal integration can look like this. But when we start using the bus, then the systems that are configured through it start to move, and the chaos decreases. Any bus would store, yes, Tatiana, well, a bus implies that we store a lot. How does a bus differ from a broker? Well, by the fact that a bus has, first of all, a very important point - this is message transformation for the recipient's needs. A powerful mechanism that allows, in case of working with non-1C systems, to do transformation, adaptation of the package for the recipient's package on the bus side. Well, that is, and we don't need to redo our export from 1C, do repeated transformations, especially in cases when the recipient system is generally not customizable, yes, that is, it can only read in its own format and gives strictly in its own format. We can enrich it on the bus side with necessary fields, add something, so that 1C can read it, for example, in the same enterprise data format. Well, and accordingly, transform the message format of the recipient system from enterprise data. So, and message routing is used, yes, we have a special protocol for routing and components of the I AM QP Broker system. So, and regarding Kafka, yes, accordingly, Kafka is precisely this distributed transmission of everything and anything. Well, essentially, like the 1C bus, it is one of these Elena, if the receiving system accepts only in Excel, yes, it is possible to transform the Excel format, that is, on the bus side, you can convert from some text file to Excel format and transfer an Excel file to the receiving system. That is, such logic can be described. Well, XLSX is also an XML format. So, in principle, some transformation can be done. The difference between Kafka and Rabbit is that messages are stored and can be stored there for as long as you want and are not deleted after processing. Well, again, depending on how we configure it. Accordingly, even when connecting a new consumer, some new 1C system, we can load historical data for a period into it. If something happens, yes, the receiving system crashes, then our bus is another backup of our system. Well, this is the weakness of the bus, as our entire company infrastructure fails. If the bus fails, well, in general, if you look visually, then there is a source system or producer, yes, a consumer system, and there is a service that simply distributes who to give what to, acting as a controller. Windows, accordingly, the simplest way to play with it is to install Kafka in Docker, yes, and, accordingly, make interaction between two 1C configurations, yes, via Kafka. And now, yes, regarding the 1S bus, it has one big drawback, that until the 1C developer has a license to play with it, we are forced to either use some beta versions, yes, of the 1C bus, or, well, where we can work with it in Enterprise. Well, maybe 1C will change the licensing system after all, and for developers, at least a two- or three-user 1C bus with some limitations. But we are waiting for such a tool so that we can also include it in our training program. What does the 1S bus allow us to do? First of all, well, it is synchronous, like all brokers, the ability to connect different non-1C systems, including routing, and perform what neither Rabbit nor Kafka can do, perform message transformation for the required system in the language of the S-executors. Routing is configured graphically. Here, in principle, the transformation mechanism is a script that converts a file from one format to another, from where it is necessary. Well, that is, there is a handler, yes, in a language understandable to us. All this can be read. Well, here's an example, yes, converting from XML to JSON, as an option. And let's just, as it is quite difficult to touch the bus in practice. How to set up synchronization of two 1C databases on the bus. Well, that is, let's go through it a bit, yes, from the integration perspective. Again, returning to the task we looked at in design, using the bus would solve most of the integration issues, yes, and all these connections between systems, yes, can be made through the bus. Well, for those who have already worked with 1C analytics, similarly, we have an application, yes, that is, a web server bus, to which a web service, to which we go. Well, that is, essentially, to IIS or to Apache. And we start creating a new application, specify what exchanges will be created, accordingly, describe the connections to them. For example, two 1C databases between themselves, describe them. Well, it's very similar, yes, to 1C. Well, here it is clear that, essentially, related teams implement all this. There is a development environment editor, accordingly, it differs radically from the configurator. To start development, yes, we create a project element. There is also a separate course for this, although many colleagues try to avoid 1C element for now, but those who have already started using it generally say that yes, it will take off. This is what Marat commented on, that using Python now is not very good. So, many still prefer some kind of USB bus and using Python instead of 1C executor. Well, this is an open question. There are other buses, but plus or minus their operating mechanism is similar. The exchange scheme, as we looked at, yes, is indicated, so there is a flow between databases, how it is built, accordingly, interaction objects. We publish the project, open the application, and then start, accordingly, describing, having saved the connection address, so that we can link the databases later. We add systems. We specify exchange prefixes. Well, this is clear in integrations. Prefixes are critical between different systems. We generate API keys for each of the systems. Here, colleagues, it is clear, yes? That is, we have a unique identifier by which we understand that our system is linked between what is recorded in the bus, yes, and the external system. Well, and then information systems. We include them in our configured application. So, we have linked our databases by issuing keys. So, we do the same for other databases. And we start the integration process, that is, we start describing the process itself. We include exchange tasks for synchronization scenarios on the side of our information bases. As an example of work, we can describe this integration through the bus, yes, in the integration bus extension, yes, as an option. We create an integration service in the extension. And precisely for the integration service, which supports redefinition through the solution, we load channels, this is all for the 1S bus, and we start describing, accordingly, the service address, our key, passwords, the interaction system, handlers for receiving messages will be created, common modules and handlers for processing incoming and outgoing messages are created. That is, all templates, yes, are generated immediately. And then we just need to add a call to process the incoming message. We connect the extension and for the second database. We also change the key and secret identifiers. Our keys. We also load channels, and we create an external processing tool to test all this, accordingly, the integration with the bus and processing, we initiate data exchange between systems. Through integration services management, we see that everything is set up here, that the databases are connected to the server. We launch message exchange, and in the databases, we include our external processing tool, which will perform the exchange through the buses. By the way, this approach, like with the bus, is also used in Rabbit and Kafka. We also formed it on a schedule using external processing. Under the hood, as we discussed at the beginning, this is an exchange plan. Don't forget. Then we configure the schedule, get scheduled background jobs, yes, accordingly, working with the bus, but this is all similar to what we discussed and checked. And we check the exchange. That is, essentially, the bus is the quintessence of all the technologies we discussed earlier. That is, it includes the exchange formats and files, and exchange plans, and the use of mechanisms, including, and not obviously, HTTP services. Essentially, it is with this that we complete our integration mechanism. Let's briefly, in what format are input and output data stored. One second. So, by default, in 1C Bus, data is stored in files in the database, that is, if not configured, but it is better to connect an external storage. This is either MS SQL or PostgreSQL. But it turns out that the data for the bus's own operation is stored there. Well, and messages rotate separately. So, file 1C. Well, if we take the same broker, no, not the broker, if we take the same 1C database on PostgreSQL, remember, then what does a PostgreSQL database represent? It's millions, maybe thousands of files. And such a 1C file system as well. So, we've gone a little over the timing, sorry, but the topic of integration is not the easiest. And there are many questions here. And without understanding them, without interaction between all these terms, it can be difficult to understand the final result, how the bus works. One second. So, logging on the bus exists, yes, Elena? So, all this is stored, logging of packages, storage, all this is configured. So, let's go through the course and go through the conclusions, nuances. As part of the course, as it happens, the block we looked at, part of it is in the design of 1C system integration, practice of working with Kafka, with Rabbit, we only consider the most relevant technologies, and, accordingly, for other processes. So, we focus on what is currently in demand in companies. Well, in terms of process modeling from the perspective of a SARCUB architect, automation of developer work, automated testing, CI/CD pipeline, and how to improve performance. At the end of the project, you will have an MVP repository set up, taking into account integration via Rabbit or Kafka, as desired. If someone has access via the 1C bus, then they can connect it, plus test scenarios so that all this functions correctly. Well, we have a whole team of instructors, you can click on each one on the website and read about them. This includes Nikita Ivanchenko, a contributor to One, who writes various things. I think Nikita Ivanchenko is familiar to some from publications on Infostart. Therefore, each person explains their block, analyzes it, and, accordingly, you can get answers to questions. So, let's summarize the integration, without them it's impossible now. So, we have covered the role of integration, the understanding of integration methods, theory. Architectural approach, at least we've skimmed through it, looked at who applies what. I think we've refreshed our knowledge. Maybe someone won't be afraid to try new technologies, to read about them, to familiarize themselves. A list of links. So, one second. So, now I'll send you a list of links in the chat. So, the presentation, I'll ask for it by email, well, a little later. So, first video training, then the presentation, accordingly, colleagues will tidy it up, so it will also be sent. So, Elena, yes, thank you for the questions too. So, our next course starts on August 20th. So. Yes, Ramil, thank you. Now, now, now, one minute. So, so, so, so, yes. Please fill out the form for the materials, if anything. Ask any questions. Yes, ask questions. So. So, Tatiana, yes, thank you for the questions too. So, let's clarify, yes, the next stream starts on August 27th, so come. There are quite a lot of questions asked, colleagues, both in lectures and in everything. There are enough assignments. The level is constantly, yes, being raised, so that those who think it's easy, it doesn't seem easy. And Git, for those who haven't mastered it, colleagues separately conduct classes on it and also make open lessons. Most likely, the next open lesson that we are planning is how to work with the Git platform. This is a free tool for managing repositories for Linux. So, yes, we will work with it, yes. So, Pavel, yes, the questions that remained unanswered, colleagues, I ask you again to send them in a personal message on Telegram, where we didn't have enough time or to cover it more deeply, then you can, yes, I will try, yes, to find an answer to all questions with our architecture. So, let's look at the dates of our training. So, yes, the next one starts on August 27th. And you can, yes, Alexander, yes, well, about Kafka, we could have talked a little more, but we will try to take it into account. It is quite capacious, and Kafka takes us almost two classes. Choice of solution. Well, regarding the choice of solution for integration, if you have questions about building any integration in your company, yes, you can also send them in a private message to help justify it. That is, it depends on the context, on the task to be solved. The example we looked at might not be very complex, yes, but nevertheless, we can also analyze, yes, as a colleague says, choosing an architectural solution can often take more than a month to justify why a particular integration should be used. Therefore, write, if there are difficulties, we will gladly figure it out, figure out how to answer them. So, that's all, thank you everyone, either some questions about work, I'm waiting. Goodbye.