1C Company has been developing software products for business for more than 30 years. During this time, the company’s solutions have evolved from a simple accounting and reporting program to multi-user ERP systems. In an urge to increase the productivity of their developer teams and equip customers and partners with an effective tool for creating and customizing business applications, 1C has introduced a platform of its own. The 1C:Enterprise has become one of the leading business application development platforms in the CIS region and has been deployed in 30 countries worldwide. By now, developers have created more than 1,300 off-the-shelf products and multiple custom solutions using the platform.
In this article, we would like to show the key differences between developing software on the 1C:Enterprise platform versus the traditional approach. Assume we have a standard business task. We need to add to a system of record (SOR) an option to enter and manage a new document type, say, production orders.
Traditional Development
A system built with an object-oriented programing language requires the following sequence:
-
Create classes to process the document type in accordance with specific business logic. In addition, the classes should also handle interaction with databases, that is, the document reading and writing.
-
Create database tables to store information about documents of this specific type.
-
Create a user interface for editing this new document type.
In addition to these three tasks that are absolute minimum for this document type to function, it is also necessary to create a form to access lists of such documents, make the documents available in reports, and ensure the system log records all user changes to these documents, and so on.
Developing with the 1C:Enterprise Platform
When developing in the platform, you go to graphic Designer, define fields of the new document type, and using the 1C:Enterprise language, setup business-specific logic (for example, you tell the system the account it should use to allocate funds recorded by this document type). The platform does all the rest automatically. Namely, it
-
Creates DBMS structures for storing respective data;
-
Creates forms for document editing and displaying the list of documents of this type. At that, automatically created forms are easy to customize if needed;
-
Makes this document type accessible in reports;
-
Makes it possible for a specific application to assign read/write rights for this new type of document or even particular fields in this type of document;
-
Includes new type document fields into full-text search across the entire system (with the support of synonyms, transliteration, fuzzy search, etc.);
-
Records all changes to documents of the new type in the application’s event log;
-
Automatically creates methods for saving and reading the documents in XML and JSON formats;
-
Makes this new document type available via the REST API (OData protocol);
And much more.
Such high-level development is possible because of the platform architecture.
Low-level tasks like creating software classes, database tables, and software libraries get “under the hood,” giving developers access to the platform components that belong to the world of business logic. These components are catalogs, documents, registers, charts of accounts, and similar.
And all of them are metadata objects designed for handling business tasks. Developers build applications out of the platform components. With an application running, the platform interprets the metadata and enables required functionality.
From the developers’ point of view, we can describe platform components as classes mapped to the DBMS. Each class has a base level. Such base-level classes are the aforementioned catalogs, documents, and registers. Any new object that a developer creates for an application must belong to one of these classes. For example, a developer can take base class Catalog and inherit catalog Clients from it.
There are about 20 components in the platform. Most of these components refer to enterprise activities, while others are technical ones that allow 1C applications to communicate with the outside world (for example, web services and HTTP services). This set of components is quite enough to cover most business needs handled by back-office systems.
Developers select components out of the list offered by the platform and specify selected component properties in the visual editor. Then the platform creates the database structure, enables database read/write operations, and draws the default user interface. This way, instead of investing a lot of effort in the time-consuming process of code writing, developers can focus on business-related tasks.
However, it is not possible to avoid coding where business logic cannot be predicted. It includes the calculation of taxes (in case of frequent changes in legislation), discounts, prime costs, etc. These tasks can be handled with the 1C:Enterprise language built into the platform. This language is easy to learn and read, and developers use it only when it is absolutely necessary.
Summarizing the above, we would like to stress that developers who wish to implement specific business logic in their applications can effortlessly do the task using the tools embedded in the platform. On the one hand, this approach limits developers’ freedom (within reason!). But on the other hand, it standardizes the development process and protects developers from many errors, allowing them to rapidly create a fully functional product. Thanks to this approach, all applications built on the 1C platform are uniform, and their behavior is predictable that greatly facilitates their use, further development, and support.
Build Once, Use Anywhere
Another key feature of developing on the 1C platform is that once you have built a business application on the 1C platform by creating a single interface and setting up the business logic, the platform enables the use of the application in different environments and on various devices.
The 1C:Enterprise platform has classic three-tier architecture, with the application server in the center. DBMSs supported by the platform are Microsoft SQL, PostgreSQL, IBM DB2, and Oracle Database. The client part is either a thin client installed on a user machine, a web client, or a mobile client.
Developers can replace libraries both during the development and later in the process of using the solution. At that, it is possible to run such a product under any OS: Windows, Linux, Mac OS, iOS, Android, or even make the solution available via a browser. The platform automatically adjusts everything to the software client currently used.
The same applies to selecting a DBMS. By choosing the appropriate options in the visual editor of the platform, a developer “tells “applications which of the supported DBMSs they should use to store data.
Thus, developers do not have to write multiple pieces of code. They create a single application using a standard development environment. This application can run on the web, desktop, or mobile and interact with almost any DBMS.
Conclusion
The development method offered by the 1C:Enterprise platform brings the following advantages:
- Ensures extremely high speed of development;
- Most of the programming routine happens “under the hood” inside the platform;
- Helps focus on implementing specific business processes rather than creating essential business functions from scratch;
- Enables solving a wide range of business-related tasks with no need to connect to third-party platforms and programming languages;
- Protects developers from many errors that might occur when working with a DBMS or OS through a standardized development approach;
- Reduces the cost of building and maintaining applications.
All the above advantages are the natural result of the platform’s specialization in a specific range of tasks, that is, automation of internal operations of an enterprise.
Got interested in building business applications with us? Start free with 1C:Enterprise!
