1C has been producing business solutions for roughly 30 years. In that time, the company's solutions have evolved from simple accounting and reporting programs to complex multi-user ERP systems. To improve its productivity and arm clients and partners with an effective tool for creating and customizing business solutions, 1C wrote its own platform 1C:Enterprise. The platform includes a development environment, a runtime, and support and administration tools. The 1C platform proved its effectiveness by becoming one of the leading development platforms for business applications in the CIS region. The platform has been used to create more than 1300 COTS corporate solutions and an abundance of custom-made solutions, implemented in over 30 countries.
Let's look at the principal differences between the 1C platform and traditional methods when it comes to software development. Take this typical business task, for instance: your back-office system needs to be able to accept and process a new type of document, such as production orders.
The following steps must be taken in an OOP system:
Write the class (or classes) that will implement the business logic to work with the document. Besides the business logic, the classes should also facilitate interaction with the DB—reading and recording the document's data.
Create tables in the database where information about the document is stored.
Create the user interface for editing the new document type. Often a form must also be created that displays the list of documents and allows you to search by various fields, etc.
Those three steps are the minimum requirement before you can start working with the document. You may also need to create a form for working with a list of documents of the new type, make the new document available in reports, and be able to register changes made by users in documents of the new type, in the system log, etc.
With the 1C:Enterprise platform, you can just outline the fields of the new document type in the graphic designer and write the code for implementing the document's specific business logic using the built-in language (for example, on which accounts the monetary values described in the document should be recorded). The platform will automatically handle all other processes to make sure the document works properly in the system, such as:
- Creating a structure in the DBMS for storing data.
- Creating a form for editing the document, displaying a list of documents of that type, etc. If you don't like the automatically generated forms, you can make your own by expanding or modifying the standard forms.
- Making the document available in reports.
- You will be able to control reading/recording permissions for the document and its fields in the application's security system.
- The document's fields will become available for full-text search throughout the system (accounting for symbols, transliteration support, fuzzy searches, etc.).
- All changes to the new document type will be registered in the application's event log.
- Methods for saving and reading the document to/from XML and JSON will be automatically created.
- The document will become available on a REST interface (via OData protocol).
- And much more.
The platform's architecture facilitates high-level development. Low-level tasks, such as creating a programming class, database tables, and a programming library, have been moved “under the platform's hood.” Instead, developers have got the platform components from the business logic world—the catalog, document, registers, chart of accounts, etc.
Platform components are metadata-driven objects designed to perform business tasks. The developer builds their application using platform components, and the platform interprets meta-data while the application is running to ensure all necessary functionality.
From the developer's perspective, platform components are essentially classes mapped to the DBMS. Each class has its own basic implementation. These classes include the above-mentioned catalog, document, registers, and others. All new application objects created by the developer must belong to one of these basic classes. For example, the developer can take the basic "Catalog" class and create a "Customers" catalog from it.
The platform has around 20 components in total. Most of those components describe patterns from a company's accounting activities, while the rest are technological components that allow the 1C application to communicate with the outside world (for example, web services and HTTP-services). These components are more than enough to cover most business demands in back-office systems.
The developer selects which platform components to use from those available and assigns properties to the selected components in the visual editor. The platform itself creates the structure for the database and reading/recording to the database. It also designs the default user interface. This keeps onerous coding to a minimum, and the developer can immediately focus on business tasks.
Coding is only used when necessary - in unpredictable business logic cases, such as tax accounting (due to frequent tax law changes), discounts, cost price, etc. The developer handles such tasks requiring algorithmic descriptions with a programming language built into the platform. The 1C language is easy to learn and read.
In summary, a developer who wants to reflect a certain business logic in their application will have a definite range of methods to handle that task with the platform's features. Although this approach limits the developer's freedom (within reason!), it standardizes the development process, protects the developer from making mistakes, and allows them to build a workable solution in a short period of time. Due to this approach, all applications created on the 1C platform are unified and have predictable behavior that significantly simplifies their use, further development, and support.
“Build Once, Use Many” Approach
Another key feature of the 1C platform is that you can implement a business application on the platform by developing an interface and assigning business logic just once, and the platform will be able to use the application with various environments and devices.
The 1C platform has a classic three-tier architecture centered around an application server. Microsoft SQL, PostgreSQL, IBM DB2, or Oracle Database can serve as the DBMS. The client end can use either a thin client, installed on the user's computer, a web client, or a mobile client.
The developer can change libraries either while developing a solution or later on while using it by running the application on any OS (Windows, Linux, Mac OS, iOS, or Android) or making it available via a web browser. The platform will automatically handle all necessary adaptations for the selected option:
The same applies to DBMS selection. After selecting the appropriate options in the platform's visual editor, the developer "tells" the application which of the supported DBMS to store data in.
This allows programmers to write less code. They write one application in one language that can be used on the web, the desktop, or a mobile device and can interact with practically any DBMS.
The 1C:Enterprise development method offers the following advantages:
Significantly speeds up development
Automatically handles the programming routine
Allows developer to focus solely on implementing specific business processes, instead of creating basic business functions from scratch
Allows developer to perform a wide range of business tasks without the need for additional platforms and programming languages
Standardizes development and protects the developer from a host of bugs that can occur when working with DBMS, OS, etc.
Reduces costs for building and maintaining applications