This is an article for those who are not yet familiar with 1C software products. It describes the capabilities of the 1C technological platform and where this platform fits in among similar software products.

What does 1C produce?

I think the first thing the general public associates with us is the popular game series IL-2 Sturmovik. However, the 1C product range extends far beyond this series.

There’s a system of applications called 1C:Enterprise that includes business application development tools and applications created with them. The 1C development tools are used to develop some accounting applications, as well as CRM, ERP (tens of thousands of user deployments), and much more.

ERP systems are the most interesting and functionally equipped business applications, so let’s explore these to see how 1C:Enterprise technologies compare with competitors’.

Existing types of ERP

What is the most valuable feature of any ERP system (and any business application)? Flexibility, that is, the capability to adapt to end user business processes with minimal effort.

It is impossible to foresee all types of business processes when programming an ERP system. That’s when parametrization is of great help; by enabling the parameters that may be changed by a user (advisor, or administrator) in the system options, we can easily increase its flexibility. The first ERP systems were parameter driven, i.e. they were configured using parameters.

However, parametrized systems alone are insufficient to accommodate all business cases. When changing system parameters is not enough, you need to change the source code. That’s when an ERP supplier needs to decide whether to change the code on its own and to release updates, taking into account the needs of the customer, or to supply the system with the source code for users to be able to rewrite the system as per their needs. The second option does not free the supplier from the need to release updates, as the system needs to develop and support new features in order to be competitive.

Another important question is the choice of a programming language for an ERP system. The major part of an ERP system is the business logic, for which regular programming languages (like C++) don’t always fit well. Ideally, the business logic will be programmed in some high-level language to provide maximum comfort to the business application developer during the business logic development process. This allows the developer to move away from low-level details (peculiarities of working with databases, file input/output and print subsystems, tabbed UI subsystem, etc.). Of course, one would need to create a compiler/interpreter for the language and the development environment.

Below, you’ll find a matrix of potential combinations:

• open or closed application code (we do not mean “open source” here in the regular meaning, but an opportunity to provide customers with the application source code, possibly on the basis of an additional fee).
• business logic programming language: standard (С/Java/Perl/…) or proprietary, specially developed.

Business applications developed with 1C:Enterprise technologies are systems with open source code written in a proprietary language that doesn’t have a short name; it is officially called Integrated 1C:Enterprise programming language or simply 1C:Enterprise script.

Most leading ERP systems are open source systems. The capability to modify source code “in the field” offers huge flexibility and competitive advantage. Closed source products need to use other technologies, the most widespread of which is an analogue of CallBacks, i.e. an opportunity to attach custom code to predefined events, both visual (form opened/closed, a value is selected from a list, etc.) and business events (order processed, sales invoice entered, etc.). Some systems support writing your own C# handlers (or handlers on other widespread languages); others use Microsoft licensed Visual Basic for Applications, etc.

Structure of ERP systems

An open source ERP system consists of its own source code that implements the business logic, and a runtime for this business code (the so-called platform).

The platform is usually written in a low-level language (C, C++), and platform source codes are often closed for end users. The platform needs to enable the programmer to move away from low-level details (peculiarities of the OS, database management system, etc.) and to be able to focus on pure business logic. Business application development tools and system administration tools are often considered part of the platform as well, and I rather agree with this. If the business logic of a system is written in a “standard” programming language, such systems use the platform as well. There’s no need to interpret application code there, but there is still a need in the platform functionality (we still need database wraps or unified access to a list of users and their rights).

As a business application runtime, the platform may be compared with a virtual machine. Usually the platform should emulate three things for ERP:

• a runtime for the business logic;
• a database;
• a graphical subsystem to render a client application. Such client application may be a graphical application (rendered with native OS tools, including mobile OS tools) or a web application. In case of a web application, the platform may either implement its own web server or provide support of standard web servers (IIS, Apache, etc.).

In general, you can make an ERP written with a proprietary language launch in any OS and store data practically in any database management system. You can do this by modifying the platform. Typically, ERP suppliers limit the choice with one or two OS and one or two database management systems. Supporting additional OS and database management systems means increased development and testing costs; often new versions of ERP products do not support some of the previously supported database management systems or even operating systems.

As far as OS and database management system support is concerned, the 1C Platform offers the following:

• Runtime for business logic: load-balanced fault-tolerant server cluster on Windows or Linux OS
• Database: private file-based database management system (recommended for development and minor installations), MS SQL, Oracle, IBM DB2, and PostgreSQL
• Client application.

The following client application are available:

• Thin client (data entry and rendering only): Windows, Linux, OSX. It can work with an application server via local network or web services (in this case, Microsoft IIS or Apache should be deployed on the server side)
• Web client: Microsoft IIS or Apache on the server side, any of Internet Explorer, Edge, Chrome, Firefox, or Safari on the client side
• Rich client (with the capability to run some of the business logic on the client): Windows, Linux, OSX. It has a number of limitations (for instance, it can only operate within the same LAN as the application server). It is considered obsolete, 1C doesn’t plan to develop it in the future
• Mobile offline client (periodic synchronization supported): iOS, Android, Windows Phone/Windows8/Windows10
  

The same instance of application code provides us with both a thin client for Windows/Linux/OSX, and a web client.

ERP applications language

The language used to create the business logic is another important decision. To ensure high performance of a business programmer, this language should be as close to the business subject area as possible (DSL, Domain-Specific Language, ideally), and not so close to the technical details of the OS and database management system.

Let’s consider a rather typical business task: we need to enable maintenance and processing of a new type of document (a work order, for instance) in the system. A system written in a “standard” language would require the following:

1. To create tables in a database to store information about the document.
2. To create a class (or classes) to implement the business logic for working with a document. Besides the business logic, such classes should also enable communication with the database in order to read and write the document’s data.
3. To create a user interface for editing a new type of document. Quite often you will additionally have to create a form to display a list of documents with enabled field search, etc.
   

If we use C# and Visual Studio, all the steps may be performed within the same development environment (including database design).

In some ERP systems that use proprietary language you also have to take all three steps described above within the same development environment.

However, this is only the required minimum: you need to develop a user interface for working with a document, to make it available in reports, to enable recording of the introduced changes in system logs, etc.

In 1С, you would have to describe fields of the new document in a graphic designer and write a code that would implement the business logic specific to a document (for instance, what accounts to debit with the money tracked in the document). The platform will take care of everything else that is required for normal work with documents in the system:

• It will create structures for storing data in the database management system
• It will create document editing forms and forms for listing similar documents, etc. If the automatically created forms are inadequate or insufficient, we can create our own by expanding and/or customizing the standard ones
• The document will be available in the reports
• The document and its fields will be available for distributing read/write rights in the application’s security system.
• Document fields will become available for full-text search in the whole system (with support of synonyms, transliteration, fuzzy search, etc.)
• All changes in the new type documents will be recorded in the application’s log
• Methods for storing and reading the document to/from XML and JSON will be created automatically
• The document will become available via REST interface (via OData protocol)
• And much more

Development in 1C has a peculiar feature: the system contains about 20 integrated object types, and all new objects created by the developer need to belong to one of those types. Most of the types describe accounting objects: registers, documents, charts of accounts, etc. Other types of objects are of a technological nature (Web- and HTTP-services, for example). They enable 1C programs to communicate with the outer world.

1С Designer is used to develop applications. To the left, you see a tree of integrated 1C types, where each branch contains applied objects of the corresponding type.

Applications are developed in Designer. A preview of 1C: Enterprise Development Tools has been recently released, which enables development of 1C applications in the popular Eclipse environment. No commercial development is yet possible in 1C:Enterprise Development Tools, but it’s a good way to understand the technological trends of the company evolving. In particular, the new system supports collaborative development with the use of popular version management systems (Git, SVN and any other that are equipped with plug-ins for Eclipse); also, developers may create their own plug-ins for IDE Eclipse to expand capabilities of the development environment to work with 1С.

Enterprise Development Tools — designing of 1С application in IDE Eclipse

In fact, the syntax of 1С programming language is very similar to JavaScript. Technically it is not an object-oriented programming language. It has no inheritance, but since all objects in 1C applications belong to one of the integrated object types, this may be referred to as simplified inheritance: integrated object types implement pre-defined functionality that can be overridden by the programmer in their inherited objects. This is a one-level inheritance: one cannot inherit from applied objects; a similar approach to inheritance is used in prototype-based programming; JavaScript is a very wide-spread implementation of this concept.

This approach deliberately limits application developers by making them select a required object type from a reasonably limited range of integrated types in order to solve their tasks. Instead, the developer receives rich functionality implemented by the platform, and really fast development. The advantages of this approach are obvious: developing accounting systems in 1C is quick and easy. Of course, there are disadvantages as well: if you need to implement anything the platform doesn’t have integrated types for (working with SFTP, for instance), you’ll have to either wait for a new version of the platform where this functionality will be implemented, or write your own implementation code with a “standard” language and call it from 1C via the add-in technology.

Some facts about the 1C integrated programming language:

• Both English (if… then) and Russian (если… тогда) syntaxes are supported.
• The language is Turing-complete.
• It is a dynamic typing language. A variable is linked to a type when a value is attached, not when a variable is declared. One cannot specify the variable’s type by declaring the variable.

Do:

var a; a = 1;

Don’t:

var a as Int; a = 1;

• 1C has its own query language, similar to SQL, to read data from a database management system. Basically, when 1C programs are run, it is translated into SQL.

How it all works

How are 1C solutions delivered to end users? How do they work with the end users?

To answer this question in detail, we need to think of one special feature of 1C.

A project in the 1C environment is called a “configuration”. A configuration is a finished self-contained application, like an accounting application or ERP; it includes all the objects and code required for the normal functioning of business applications. 1C is peculiar, because the configuration is stored in the same database as the application data, i.e. transactions, register and document data, etc.; so a program is stored together with the data. A database that contains configuration and application data in 1C is called an information base (infobase).

A configuration can be uploaded into a file; it is usually delivered to end users as a file and imported into an infobase in the customer’s system. The solution is ready to work.

Architecture of 1С solutions

Location of the software:

• Database management system server: one or several database management systems supported by 1С (MS SQL, Oracle, IBM DB2, and PostgreSQL). If several 1C applications are installed on a 1C server, they may use different database management systems: MS SQL for accounting and Oracle for ERP.
• Server: one or more servers of a fault-tolerant scalable cluster. 1C Server software is needed here - a set of special libraries and executables. Fault-tolerance and scalability of the cluster, as well as load balancing between servers of a cluster, are supported with 1C software tools. One cluster may contain both Windows and Linux servers, and the system may contain a redundant cluster.
• Client: Windows or Linux or OSX OS, thin client (1cv8c.exe/1cv8) or 1C rich client (1Cv8.exe for Windows and 1cv8 for Linux) installed.
• Web server: IIS or Apache. A set of extensions for web servers is installed by 1C.
• Web client: any of the supported browsers, including Internet Explorer, Chrome, Edge, Firefox, and Safari.
• Mobile client: iOS or Android or WindowsPhone/Windows8/Windows10, and any 1C mobile application. The way the 1C mobile application communicates with the server depends on the specific application; they usually use web- or HTTP-services.

The client applications have the following limitations:

• The thin client supports a limited set of 1C integrated language functions and operates a limited set of types of an integrated language, which is only needed to display and modify data in memory. All database manipulations and object data, as well as query processing, are performed on the server side. The thin client receives the data ready for rendering.
• The rich client supports almost any functionality provided by the 1C integrated language; it uses the server only to read or write data from/into the base. Limitations: demands significant hardware resources and may “communicate” with the 1C server cluster via LAN only. Considered obsolete, supported for backward compatibility.

1C components (the server, thin and rich clients, and web extensions) communicate with each other via their own protocol (implemented over TCP) or via HTTP.

What’s so special about 1C

What are the competitive advantages of 1C:Enterprise? Thanks to our innovative approach to development (see below), it is significantly easier to do two things in 1C:Enterprise - create business solutions from scratch and customize existing solutions for end users.

Development

It is very easy to build a solution from the ground, because the basic functionality of accounting systems is implemented by integrated objects. A well-thought out system of integrated objects (not the language, which is a usual script language) makes 1C:Enterprise a powerful business application development tool. Developers do not have to create a data access layer, a basic UI, etc.: they can get straight to solving business tasks. Many tools for dealing with these business tasks have been implemented in integrated objects (basic libraries), including support for hierarchical registers, accounting machines for basic and stock accounting, mechanisms for complex regular payrolls, and much more.

Developers receive integrated objects (registers, documents, ledgers, etc.) out of the box, implemented by the platform, as basic accounting patterns. These patterns are implemented in the application (configuration) by populating them with specific business logic.

An application in 1C: Enterprise is not written literally with a programming language. Two cornerstones of the development ideology are Metadata-driven development and Model-driven development.

The core of a business application is metadata, which is a declarative description of the application itself. The application is not described in terms of relational tables, classes of object-oriented programming language, etc., as in most systems. The application in 1C:Enterprise is described with metadata as a set of application objects selected from a defined set of prototype patterns (registers, documents, charts of accounts, etc.).

This metadata forms a hierarchy of objects, which are the building blocks for all the constituent parts of the application system defining all aspects of its behavior. When a business application is running, the platform interprets metadata and provides all the necessary functionality.

Metadata is used to describe data structures, type composition, connections between objects, their behavior and visual representation, assignment of access privileges, user interface, etc. It contains information on what is stored in a database, why it is stored there, what the role of this information in the system is, and how these information arrays are interrelated. The use of a programming language is limited to the tasks that require an algorithmic description (tax calculation, validation of data entered, etc.). Briefly, development with 1C:Enterprise may be described as follows: “let’s code only when it is strictly necessary, and allow the platform to do all the routine”.

1C:Enterprise is initially oriented toward building applications based on a certain model. “Model” means the whole philosophy of creating an app. This includes data structure construction methods, types of connections between data, data manipulation principles, forms of business logic description, methods used to link data with interface objects, distribution of functionality between system levels, and much more.

All business applications follow a generally accepted model, which ensures the consistency and predictability of their behavior. A developer that needs to reflect the specifics of a certain subject area in the solution has a well-defined set of methods to achieve this with the platform-integrated tools. On the one hand, such an approach (deliberately!) restricts the freedom of the developer, but on the other hand, it prevents many errors and enables building a valid solution within a very short period of time — a solution that can be further extended and supported by the same developer or other staff members.

The use of a single model improves the adoption of the system. The entire development process is based on one end-to-end conceptual framework and a single space of data types. The description of certain objects (entities) in metadata defines both the appropriate types of the integrated programming language and the database structure required to store them. All further manipulations with these entities (both in memory and in the database) are unified and do not require overcoming barriers between different notations used in working with a database management system and universal programming languages.

A ready to use application (configuration) is delivered to customers as open source codes (accounting or ERP, for example), and it is almost a DSL (Domain Specific Language) for the customer’s programmer, who can use out-of-the-box configuration objects (catalog of contractors, chart of accounts or payroll) to customize the system’s behavior in accordance with the customer’s needs.

Customization and support

The business logic of an application can be modified. Changes can be made by a customer’s IT staff: they adjust the solution to the business processes of an enterprise. It can also be modified by the solution supplier who adds new functionality, supports compliance with changing regulations and releases updates regularly.

Installing an update in an environment where the business logic was adjusted “in the field” to fit the customer’s needs is quite a challenge and is fraught with errors. Generally speaking, we are talking about merging source codes of a new supplier-provided application with a modified version used by the customer (which differs from the previous supplier-provided version). On the one hand, you need to obtain new functionality provided in the update; on the other hand, you can’t afford losing your own customizations.

This situation is familiar to anyone who has ever worked as part of a team on one application and tried to merge their source code modifications with modifications made by other team members. Even if all members of a developing team follow the same development and coding rules, merging source codes may become quite a challenge. When we deal with ERP systems, this is complicated by the fact that developers of the supplier and the customer work in different organizations and rarely have an opportunity to communicate if they have difficulties with understanding the code.

We should notice that if the changes implemented by the customer are significant, the supplier may refuse to provide further support of the solution.

The situation described above is one of the most complex tasks in the life cycle of almost any open source business system. The market success of the application depends on how a software vendor deals with this situation. In our case, merging two configurations (supplier‘s and user’s) after an update is not a mere merger of source codes of two applications: we are talking about merging application models that need to follow certain rules.

To solve the problem, 1C has developed a support mechanism integrated in 1C:Enterprise platform, which enables the solution supplier to define which configuration objects (catalogs, documents, etc.) can be changed by a customer and which cannot, since their modification will damage the performance of the system or will make it impossible for the supplier to provide centralized support in the future.

In turn, the customer may use this mechanism to define the support rules for their own configuration objects: for example, the customer may reject the support offered by the supplier of a certain object, if the customer takes responsibility for further modification of the object or if the object is not needed anymore. Alternatively, the customer may prohibit editing an object of “their own” configuration to prevent accidental modification, even if this is allowed by the supplier.

Ideally, custom modifications would exist somewhere aside, away from the supplier’s standard configuration and be enabled only during the code execution. This could make installation of supplier-provided updates a fully automated process. 1С suggests two approaches that support the majority of customization scenarios.

The first one is related to the use of external data processors and external reports. These technologies enable “adding-in” extra functionality on top of the system without changing the source code of configuration. Basically, these are scripts with a graphical interface meant to be launched in certain applications. These technologies gave rise to an online store (similar to the App Store, in Russian), where independent programmers publish, and end users purchase the required add-ons for different applications.

The second approach appeared not so long ago. It is related to the use of extensions. The extension-based strategy suggests that there’s no need to change the standard configuration. All modifications are included into a so-called extension, which is also a configuration in a way, but a custom configuration that exists separately from the supplier’s configuration. Installation of supplier-provided updates is automated, as the standard configuration hasn’t been changed from the point of view of the support technology. The final configuration (a combination of standard configuration and an extension) will enable the objects added or modified in the extension.

What else?

What else is worth mentioning among 1C technologies? We provide a list of the most important technologies, and each of them is worth a separate article or even more:

• 1cFresh cloud solution - an “out-of-the-box cloud”, a scale-out environment for working with 1C applications (and partner applications) in the SaaS model. The product contains all the functionality required for SaaS: user registration and management, quick publication of new applications, user data backups, etc. 1С uses 1cFresh to lease its products, and sells 1cFresh as an out-of-the-box solution enabling partners and customers to deploy their own clouds for 1C:Enterprise based applications.
• 1С Mobile Platform (mentioned above) allows programmers to create applications for mobile OS (iOS, Android, Windows) based on the same source code by using the same methodology and development environment (Designer) as for “standard” 1C applications.
• Powerful and flexible reporting system. Reporting is a very important component of any business system: many ERPs use third-party external report generators, because developing a good report generator is quite a complicated and highly specific task. In 1С, reports are generated in the same environment (Designer) that is used for application development; the reporting technology is based on the data composition system, i. e. a mechanism for declarative report description. One of the important features of 1C reports is that an end user may customize the report created by the developer using the same report design capabilities.
• Data exchange technology enables developers to create locally distributed information systems that exchange data in offline mode without constant connection. Data exchange is supported both between 1C:Enterprise applications and between 1C:Enterprise applications and third-party systems.
• And a lot more

1C: Enterprise: technologies and tools

In conclusion

Hopefully, those who were not familiar with 1C now have a clear picture of 1C technologies, the way they work and what capabilities they offer to developers. We have a lot of interesting topics to cover, but let’s leave them for the next time.

1C selected a platform-oriented approach to application architecture in the mid-90’s. Such a unique combination of a powerful platform and reasonably limited application-oriented programming language has proven itself. Over 1,000 solutions officially certified by 1C for different industries, including small business automation and corporate management with thousands concurrent users, have been developed on the basis of 1C technologies to date.

Naturally, this sets special requirements for the platform. Taking into account the wide variety of technologies supported, the platform ensures the quick and reliable operation of all its applications. 1C Company has already achieved a lot and is still going.