In the article of the head of economic program development department of “1C” company Sergey Nuraliev the architectural and technological innovations implemented in “1C:Enterprise” are examined, which have identified in aggregate a number of completely new technologies of business application development and new qualities of these applications.
The article is published in the newspaper PC Week/Russian Edition (published under license of international publishing house Ziff-Davis Media Inc.), NN 46 , 47 and 48 in 2004. This article version is published with permission of PC Week/RE. A number of additions are included in it which were included in newspaper version for the technical reasons, as well as the illustrations are added.
“1C” company thanks the editors of PC Week/RE for cooperation and assistance in the preparation of this article for publication.
TABLE OF CONTENTS:
- A view from the over side
- What we are fighting for
- Platform and business applications
- Metadata – the way of business application description
- Application construction based on the model
- Data management
- Standard prototypes of application objects
- Application objects and mechanisms
- High-level interface model
- Intelligent reporting mechanisms
- Construction of distributed and integrated information systems
- Delivery and update of application solutions
- Summing up the results
A view from the over side
Today almost every second product of human activities offered to the customer is related to high technologies. And this means that it not only meets the specific individual needs, but also is the embodiment of scientific and engineering idea. Obviously, in some cases the ideas and achievements realized in the product fully define its essence and consumer value.
In this article we decided to concentrate on the description of “1C:Enterprise” product features, namely, on the technological innovations that have defined in aggregate a number of completely new technologies of business application development and new qualities of these applications.
Firstly we will make a small remark on terminology. This article is not focused exclusively on those who has a deal with “1C:Enterprise” program system. In our opinion it can be interesting for many specialists who is interested in the development of economic and corporate application development, regardless of which products do they work with. Therefore, in this article we will try to use only the minimal volume of terminology specific for “1C:Enterprise”. In some cases we will use various terms for the close concepts outlining their analogs and necessary clarifications.
A small clarification is required for the product name. “1C:Enterprise” is a program including platform and a set of constructed on its basis business applications which are designed for a variety of sectors and enterprises of all scales. In this article we will talk mainly about platform on which the business applications are constructed.
What are we fighting for
At the beginning it is desirable to briefly determine what to consider the main aim of such technologies construction as a “1C:Enterprise” platform. If you look at the history of computer and programming development, you can see that along with increasing of performance, data volume processing, usability, etc. it is traced a quite clear desire to rise a level of program system abstraction. This trend is some of the unique properties inherent exactly the computing, while in the other areas of human activities the strategic development goals have more utilitarian nature. To trace the history of rise of abstraction level is very simple – from patch cords programming level to the machine codes, assembler, structural programming languages, etc. Each stage was a sign of rise of abstraction level of interaction between human (and developer, and end-user) and computer.
So, the main task of “1C:Enterprise” platform is first of all an implementation of this approach during development and usage of business applications. Of course, at the same time the traditional tasks are solved associated with performance, ergonomics, functionality, etc. But it is the rise of abstraction level that enables to pass from technical and low-level concepts to more meaningful and high-level, and thus to bring them closer to the language of the users and specialists in the subject area. In the end this allows significantly speed up and unify both system design and its maintenance.
Platform and business applications
Perhaps the most conceptual in “1C:Enterprise” architecture is the presence and the concept of business application. Of course every business software company-developer has a enough powerful toolset of technologies which help to build its solutions. However, when developing “1C:Enterprise” we initially focused on the creation of fully functional, integrated platform which will be used to construct various business applications not only by “1C” company, but also a lot of other companies-developers familiar with the specifics of particular sectors. That is why the platform was initially created as a replicated product, which includes both the necessary technologies for business application operation and the tools for their development and modification.
In “1C:Enterprise” it was introduced a well-defined separation of the platform and business applications. The platform is a so called framework in which business application operates. We could not find an exact translation of this word in the Russian language. From one side the framework can be considered as a foundation for application construction, and from the over – as a runtime environment. Besides, platform, or course, has also the tools necessary to develop, administer and maintain the applications. Such application is an independent entity and can act as a standalone software product, but relies entirely on the platform technology.
Note that the concept of platform and platform oriented application construction is now generally accepted and is treated wider than simply the ability to work in specific operating system. Under platform means the runtime environment and a set of technologies used as a basis for construction a specific range of applications. In fact, the applications are based on several platforms, which form a multilayer cake. It is important that the platform provides the developer a specific model, which usually isolates him from the concepts and details of lower-level technologies and platforms. Such is a “1C:Enterprise” platform which allows to use different technologies of lower level without changing the business application code.
For example it provides the developer his own model to work with data and isolates him from the features of specific data storage, and this allows to use different storages without changing business applications. For instance, during solving a small scale task the own file engine can be used as DB, and in scale of enterprise work – MS SQL Server.
The key quality of “1C:Enterprise” platform is perhaps the adequacy of its resources to solve the tasks facing the business applications. This allows providing a very good consistency across al the technologies and tools used by developer. After all, it is the presence of “the seams” between different technologies that is a cause of the most serious problems. The simplest example is a system of types. In “1C:Enterprise” platform the developer uses one system of data types for DB interaction, business logic realization and interface solutions creation:
Therefore, his has no problems with conversion of types between different levels of application system. Another very important moment is standardization. The availability of a single platform for a large number of application solution assists to form a common “cultural layer “, which includes both the people (programmers, analysts, users) and methodology (typical data structures, algorithms, user interfaces). Based on this “cultural layer” the developer spend a minimum efforts to find the necessary solution almost in any situation, from inclusion of the new specialist in the project to implementation of some subsystem of business application according typical methodology.
One of the essential advantages of clear separation between platform and business application is the high level of solution adaptability to the user requirements.
It should be noted that exactly for the economic tasks it is especially important the ability of effective changing of ready solution by the developer who did not participate in its creation. In the business application development industry, in contrast to many other areas, significant part of developers do not create the programs “from scratch”, but modify and develop the typical solutions.
This fact determines the specific requirements to ensure the clearness and simplicity of the existing solutions understanding by the developer and is maximally taken into account in all platform mechanisms.
The instrumental tools of “1C:Enterprise” are not some additional “toolkit”, but in integral part of platform. They are oriented equally both on solution development and their adaptation during introduction on a specific enterprise. These tools are supplied with each 1C:Enterprise kit and are applied both to enter small changes, for example, in printing form prototype, and to significantly modify the application solution including data structure and business logic. The abilities of effective application alteration during its introduction are incorporated in these instruments, and, in addition, the architecture of application solution construction contributes to this. In the following sections of the article we will try to illustrate this thesis.
Allocation of business application as an independent element, in fact, allowed us to form an industry of creation, distribution and maintenance of various application systems, which concentrates its efforts on the specifics of this class of problems and does not require a deep understanding of the most part of technological details. For example, for a company, which has specialists, experience and reputation in specific branch it became a quite real in a short time to enter the market of business applications with its own product without spending several years for technological base creation.
Metadata – the way of business application description
In “1C:Enterprise” the application solution is not literally coded in programming language. Of course, the programming language is used, but only where it is really necessary.
Metadata is at the heart of business application. It is its structured declarative description. Metadata forms hierarchy of the objects from which all the components of application system are formed and which determine all the aspects of its behavior. In fact, during business application work the platform “plays” (interprets) metadata ensuring all the necessary functionality.
Metadata describes the data structures, the type composition, the relationship between the objects, the features of their behavior and visual presentation, the system of access rights, user interface, etc. Metadata, in fact, concentrates information not only about “what to store in database”, but also “why” is this or that information stored, what is its role in the system, and how are the information arrays connected. The use of programming language is limited usually by solving the tasks, which really require an algorithmic description, for example, tax calculation, validation of the entered data, etc.
What does this approach of business application construction give? Firstly, in metadata description it is widely used the visual editing. This allows adding up the significant development part to a visual design, which does not require a laborious coding. But this approach has another important advantages. Describing the application solution in terms of metadata the developer “tells” the platform many useful information, which it can effectively use in for various purposes. On the basis of metadata the system automatically “builds” the most part of mechanisms and objects, which provide the operation of application solution. For example, the metadata description is enough for platform to automatically form the user interface of the system, which provides the input and editing of interconnected information. Another example – the ability to construct a complex reports by the end user who has no programming experience.
The ideology of metadata usage in the most general terms comes down to the simple thesis: “Let’s no program all the functions of developed solution. Tell platform about composition, structure, features and interconnection of its different parts, and let it do the rest by itself “.
This ideology (Metadata Driven) today meets more widely implementation in all perspective developments.
Application construction based on the model
“1C:Enterprise” initially included strict focus on the construction of application solution based on the model.
This approach is very promising and according our estimation it will be the dominant in the foreseeable future in the modern development tools. The ideas of construction of business applications based on the model, for example, were embodied in MDA architecture (Model Driven Architecture) of OMG consortium.
The model refers to all ideology of application solution construction. It includes the ways of data structures creation, the types of data relationships, the principles of data handling, the forms of business logic description, the ways of data connection with interface objects, separation of functionality over the system level, and more.
It is important that all business applications strictly follow the accepted model and this provides the uniformity and predictability of their behavior. In fact the developer who wants to reflect in the application solution the specifics of a particular subject area has a well-defined set of ways to solve this task using the tools included in the platform. On the one hand, such approach limits (quite sensibly) the freedom of the developer, but on the other – it protects him from a variety of errors and allows getting a workable solution in a very short time, which can develop and be supported in the future both with him and, if necessary, with other specialist.
The obvious consequence of this approach is the isolation of business application developer from the details of the technologies of data storage, three-level architecture organization, etc. For example, it was stated before that all application solutions based on “1C:Enterprise” without any changes operate both with their own DB file engine and with DB server. In this case the necessary data structures are created and changed by the system automatically on the basis of metadata description, and the developer has no to understand the details of the storage formats for specific DBMSs. Application data handling is also described in the high-level model and is automatically executed subject to the characteristics of the used storage.
According our evaluation the availability for developer of specific model, which is separated from the used tools, will be the dominant in the foreseeable future in the modern development tools.
The presence of a single model crucially affects the ease of system familiarization. All development is conducted within a single pass-through conceptual system and in a single space of data types. The developer has no need to become familiar with several models of presentation and to spend the efforts to implement the transition between them on the different levels.
For example, the description in metadata the particular objects (entities) defines at once the appropriate types of the built-in programming language and the necessary DB structures for their storage. All subsequent manipulations with these objects both in memory and in DB are executed consistently without the need of overcoming “the barriers” between different notations accepted in work with DBMS and the universal programming languages.
One of the key differences between business applications and the programs of other purposes is the paradigm, which they use to handle the data.
It is obvious that for economic tasks the work with data is the major content from the one side and the most problematic from the other. It can be explained by the fact that if the most areas of program system creation have already reached some level at which the program products are “close to perfect ” (for example, in text processors), then in the area of economic software it is, to put it mildly, far away.
The economic applied systems are constantly “under the oppression” of the ambiguous requirements. On the one hand it is necessary to process the big data volumes and on the other – to provide a versatility and high performance. The volumes of processed data grow, the requirements for the diversity of the solved tasks grow and the requirements for scalability also grow. You should not forget about maximizing the development comfort, the system usability, the possibilities of their update, etc. In the modern world practice there are several paradigms of data handling which are used in the tools of business application development in different combinations. Therewith it is far away from ideal – all existing and developed technologies are the compromise solutions aimed at improving the system metrics according several given criteria.
Of course these contradictions are related to all the system aspects, but they appear most brightly in the ways of data handling.
In the modern world practice there are several paradigms which are used in the tools of business application development in the different combinations.
“1C:Enterprise” provides the mixed approach which on the one hand has many in common with the approaches included in the advanced developments of the other companies, but on the other hand it has also the significant differences.
For all operations of data modification (creation, alteration and deletion) in “1C:Enterprise” the object technique is exclusively used. It means that the developer interacts with DB not at the record level, but using the objects which match the entities stored in DB. To modify the stored data he does not need to write the complex queries and convert the results of their processing in the objects of programming languages. It is enough to get the object from database, change its properties and save again. The developer has thus the possibility to write the event handlers connected with data modification executing them using different tests and changing, if necessary, the other data. The system provides the effective support of objective approach by performing, for example, the object caching, the control of object and referential integrity, etc. To read data you can use both objective technique and the declarative query language that is based on the classic SQL, but has a set of significant extensions. The extensions are designed on the one hand to support the work with the objects stored in database, and on the other – to effective solve the economic tasks. Thereunder we will consider the query language more in details:
One of the key benefits of objective-relational paradigm of data management is a clarity and simplicity of application development. The objective technique used mainly for data modification provides a very good readability of business logic algorithms, significantly reduces a number of error during development, as well as provides a high level of data integrity. Besides an important feature of objective technique is the fact that thanks to a strict granularity of data handling it simplifies the transition between distributed and integrated systems.
The declarative query description, in turn, allows getting arbitrarily complex data samples and provides the powerful aggregation abilities necessary to solve the analytic tasks.
In our opinion such mixed technique in one form or another will start in the foreseeable future to be used widely enough in the advanced developments of economic systems.
Here, a little looking ahead, it should be said that in “1C:Enterprise” model the most modern concept of information work is implemented which combines three ways of data representation –entities storage in database, their representation in programming language as the objects and mapping in XML format. In fact any information can be represented using one of these ways depending on the current work mode.
The longtime entities storage (persistence) is performed in DB that ensures the reliability and effective processing of big information volumes. For modification the data are firstly converted in the objects of built-in language. During internal exchange in the distributed DB or interaction with other information systems the data are transferred in XML format:
Note that all three ways of presentation are based on a single system of concepts and there is no need in the developer’s efforts to transform data from one way of presentation to another.
Such approach allows to perfectly fit “1C:Enterprise” in the future heterogeneous solutions, which, in our opinion, (and it coincides with estimation of other experts) will be with time the most widespread.
One of the distinctive features of “1C:Enterprise” model, which has no, as we believe, the direct analogues in the other similar systems is a separation of all applied data on those that have the objective nature and that do not have it. Note that for handling both of them the objective technique is used.
Such separation corresponds to the real data nature. In the subject area there are always the entities that have the objective nature, for example, “customers”, “persons”, “commodity”. Here the object has a specific “self-sufficiency” which is not dependent from the data describing it. For example, a person can change the second name, first name and passport, but for us it is important to know that this is the same person (unique object). On the other hand there the entities without objective nature. For example, the record of arrival of some article on some warehouse is only information about article’s movements and has no other content except the stated in record. When replacing in such record one article by another the meaning of the record about article movement will completely change. In other words, for this entity the record without specifying the fields’ values has no sense.
As a result of such conceptual separation of entities the “1C:Enterprise” platform provides in fact for the developer a ready methodology for the most natural solution of different tasks for data handling according the nature of these entities.
The work with objective entities is supported be presentation of the database entities as the objects of the built-in programming language, as well as the special data types serving to represent the objective references (references of database objects). In this case by knowing the object it is easy to get its reference, and by knowing the reference – to extract the object from DB. This technique provides an intuitive and natural way of description in the source code the business logic algorithms which handle the objects, and, besides, guarantee the logical integrity of data during any operations. It recalls writing the object DB applications with the only difference that the data saving is executed in the tables of relative DBMS. Thereby in the modules written on the built-in language it can be available several objects at the same time representing the same DB entity.
The mechanisms of platform provide the support of the unique objective identifiers (references), the control of objects versions, their pessimistic and optimistic lock. Optimistic lock guarantees the logical integrity of the objects modification, and pessimistic allows organizing the simultaneous editing by the users the same objects in the “1C:Enterprise” interface. The platform optimizes the operations of the objects reading using the mechanism of their caching both inside transactions and outside them. During objects modification the technology of “smart record” is implemented: the system monitors their changes and really saves on hard disk only modified data providing, however, the integrity of this operation.
The work with non-objective entities is carried out using the set of records which are in fact the collection of records. Such collections support the reading and modification of data with required for the applied logic granularity.
It is important that both defined approaches allow adopting a simple and natural style of business logic algorithms writing. The developer who needs to modify the existing in application business logic when reading such algorithm quickly understands the subject matter and can easily debug and correct the source code. Now to interact with database the developer does not need to program by himself the complex information conversions from the object structures to the relative that greatly improves the effectiveness of software creation and debugging.
Another important feature of objective technique implemented in “1C:Enterprise” platform is the fact that the objects that are in the modules on the built-in language (both for objective and non-objective entities) are also used to represent the data in interface. The form control elements are directly associated with the necessary objects and provide their representation and editing by the user without any help from the developer’s side.
For the objective entities the “1C:Enterprise” platform supports the mechanism of representations. It is responsible to represent in interface the values specified by the references of database entities. If it is necessary to represent the reference value, the system automatically forms representation based on the metadata properties optimizing, as it is possible, the receiving of information from DB using caching and other mechanisms. In the processor of query processing and reporting the representation are also widely used. This allows uniformly getting the representation of reference fields if the query is formed to represent the data in the user interface, and automatically include the representation mappings in the reports for the fields containing the reference values. It is important that the mechanisms of representations gives the opportunity for the developer to simply and naturally handle the object references minimizing at the same time a number of DB calls.
In addition to the above-mentioned methods of data handling and query forming the system provides one more way of data access – the dynamic samples. This mechanism allows accessing to very big data volumes providing the information reading by portions. In this case the developer only specify which data he wants to get and the system automatically executes the calls to DB with necessary granularity. It is important the for this task solution does not use any specific tools for dynamic reading of particular DB, which require the storage in memory the opened sample, but it is executed the automatic querying consistently choosing the record blocks.
Another important solution of work with data in “1C:Enterprise” is a support in table fields the compound data types. This ability, as far as we know, has no close analogues in the other systems. During description of the field type of some object it is possible to choose not only one of the existing types, but almost any their combination (with some restrictions). For example, in the field “Payer” of document reflecting the bank operation it is allowed to store the reference of juridical of physical person depending on a particular operation. Although the example is simple enough, the ability to work with the compound types allows solving such tasks as storage of arbitrary commodity characteristics, analytical accounting of business records of any analytical cuts configured by the user, etc. It is important that the system not only provides the ability to store in one field the miscellaneous values, but makes it by the transparent for the developer way. First of all, it should be noted a full support of work with the fields of compound types of database “engine” and query language. For these fields the full collection of standard operations is supported (comparison, aggregation, etc.). Another important moment is support of compound types in the interface mechanisms of the system. For example, the input field associated with the data of such compound types provides all the set of editing opportunities (type selection; editing of values of all types included in this field; restriction of the chosen types).
A careful attention should be paid for the query forming in “1C:Enterprise”. We already mentioned that they are based on the constructions of standard SQL language, but have a set of significant extensions.
First of all, we should mention support of the objects in query language stored in DB. All operators of query language provide the work with the reference types (the fields that store the references of DB objects). For example, the query to the fields is supported in the notation “through the point” without restriction of level numbers. You can specify in the query the sample of such field as “Article.Manufacturer.Country.Name”. For the database objects it is allowed to query the nested tables both as the separate tables and the usual object fields containing the record collections.
Another important quality is the operational implementation of the function of multidimensional results formation with an arbitrary order of measurements traversal. In this case such opportunities are available as combination of multidimensional traversal of measurements and multidimensional traversal of the values hierarchy of each measurement (for example, the multidimensional structure of the subdivisions or multidimensional commodity grouping). A set of special modes of the results processing is also supported.
The query mechanism is able base on the properties of the applied objects specified in metadata to organize the samples automatically. This allows the developer, when creating the query designed to get the report or visualize the data, do not specify by which fields the ordering should be done, but with enabling the automatic mode to get the standard sorting for the selected data.
One more powerful tool of the query mechanism is the virtual tables. They provide the access to the derived data provided by the various applied subsystems without requiring for this the writing of the complex queries. For example, you can query the virtual table to get the distribution of residues and turnovers of the commodity on the warehouses and nomenclature, as well as on the calendar periods. It should be noted that the work with the virtual tables is not synonymous with a simple storage of the typical queries (view). During the virtual tables usage the developer specify the set of parameters describing the necessary sample taking them not only as the particular values, but also, for example, the complex conditions. The application solution developer works with the virtual table practically as with a usual, but the system forms the DB query so that in order to ensure the maximal effectiveness. In particular, during data querying processed by the accounting mechanisms the stored by them intermediate results can be used.
Standard prototypes of application objects
If we talk about the differences of business applications and the tools of their development, the most important probably would be the question what terms (we even could say “what paradigm”) describe the application. Of course, each development tool can use several description ways, but one of the sets of concepts is always a fundamental.
The examples of the existing approaches result in a description in terms of relative tables, the classes of object programming language, stored entities (Entity Persistent), etc.
In “1C:Enterprise” development model the approach is used for which we did not find an obvious analogue in the other systems. Here the whole application solution is described by metadata as a set of application objects selected from a rigid particular set of prototypes (classes). We could even call the created objects by the business components and their prototypes – by the templates (patterns). Each prototype is responsible to represent in application solution a particular set of the objects or processes of subject area that have similar behavioral characteristics and a similar role in the overall picture of solution.
The examples of such prototypes in “1C:Enterprise” are “Manuals”, “Documents”, “Accumulation registers”. Each prototype has some basic implementation which defines the properties of functioning created on the basis of this object prototype: the structure of the stored entities together with some predefined fields, the collection of programming language types, the methods, properties and events, as well as the typical for the solved task operations, the ways of representation and editing, the methods of access rights control, etc.
If during development it is necessary to create an object that reflects the features of subject area, the programmer selects the appropriate prototype and creates an object of metadata based on it. Further he can specify different properties that define the behavior features of the object based on this prototype, add if necessary the data structure of the object, implement the necessary set of methods, define the event handlers, specify the ways of the object representation in interface, etc.
For the simple objects this extension of a definition may not be necessary at all, and the whole procedure of the object creation will be reduced to specifying its name in the metadata properties. In more complex cases, the developer is able to specify particularly enough both the data structures and the business logic algorithms, but in this case the standard functionality is implemented automatically without any efforts from his side.
It is important that a number of such prototypes in the platform is not large, about two dozen: it is easy to learn them in order to effectively apply them subsequently for any tasks solving in the subject area.
Thus, the structure of “1C:Enterprise” metadata is not only the set of object descriptions in some unified terms. The whole application solution in fact consists of the objects that are clear separated by the roles which they play in the business application. Such approach significantly increases the effect of the system description in terms of metadata, as well as the application construction on the basis of model.
The presence in the objects described the metadata the standard functionality and predefined role allows the system to automatically solve much wider range of the tasks assigned both directly with the objects and with the general mechanisms working with them. In fact, knowing the function (the role in the application solution) of the particular object the platform provide for it the appropriate “individual approach” in any situation by itself, without any participation of the developer. For example, the form mechanism “knows” who better to edit a particular data, and the standard report mechanism can automatically “adapt” to perform the information analysis most effectively.
The use of predefined prototypes provides the standardization of the model of application solution construction. Such standardization is not very sufficient for a separate business application, but it is of great importance during construction the development industry and support of multiple application solutions. Standardization allows significantly simplifying the design tasks and reduces the support complexity and work content by several times. For example, if it is necessary to connect to the project one more specialist or to transfer to another employee the solution support and upgrading, the new developer can after a cursory inspection of metadata structure just to get an idea about application solution composition and functionality in a few minutes, because the metadata structure combines all application objects according the functional roles accepted in the “1C:Enterprise” model. In the future he can also quickly understand the organization and business logic of the individual subsystems. By experience these parameters significantly differ from those obtained by using the other approaches of application description.
Application objects and mechanisms
We have described above only the principle of application solution construction based on the use of standard prototypes of application objects.
Of course this is not the place for a detailed description of all available prototypes. But, in order to demonstrate the ideas implemented in the existing model of the business application construction, we will give below a brief overview of the prototypes and the opportunities provided by them.
First of all we will give the examples of the simple enough prototypes – manuals and documents. The manuals describe the directories which content is more or less constant. It can be a list of output product, a list of company’s clients, a list of currencies, etc. The manuals provide the support of hierarchical structures, allow referring the data to the individual objects and their groups, and provide a range of other service opportunities.
The documents represent the events of the system that happen in the enterprise life: arrival of materials, money transfer through the bank, hiring an employee, etc. This prototype provides their representation in different accounting mechanisms supports the control of event handling order, implements the continuous numbering of the objects with different types, etc.
Let’s talk about some capabilities of these two prototypes more in detail.
It is known that the classic relative model does not have the ready tools to support the data hierarchy and its implementation always requires a hard work. The manuals (as well as some other prototypes of “1C:Enterprise” application objects) initially support multi-level hierarchy. This mechanism becomes enabled using a simple activation of the appropriate option in metadata. Meanwhile the hierarchy support distributes on the all aspects of application object implementation at once. For example, the prototype provides support of the necessary options and methods in the object model of data handling (object level determination, control of hierarchy circularity, etc.). In the interface mechanisms data presentation is implemented as the hierarchical list or tree with navigation by levels and interactive changes of hierarchy. The report mechanisms provide the forming of hierarchical documents of this style and receiving the multilevel hierarchy of results in any reports in which the objects of this type act as the grouping parameters.
Another example of the regular prototype opportunities is support of document execution mechanism. This mechanism provides developer the standard model of connection organization between information about events that happen on enterprise and different accounting mechanisms. Any information entered by the user as the documents can be represented in any accounting mechanisms (planning, management accounting, business accounting, etc.). The developer only has to specify in the metadata options the relationship between documents and accounting mechanisms, as well as to describe the document execution mechanism. All the necessary actions for execution and cancelling the execution the system will perform automatically. Meanwhile the additional opportunities are available, such as support of real-time event representation, support of recovering the sequence of representation of the events that happen on enterprise during their changing post factum, etc. As a result, a single model of relation between the source data and the accounting mechanisms is provided which not only simplifies the development, but also provides uniform and predictable behavior of all application solutions that significantly facilitates their learning and support.
Quite interesting are the prototypes of “1C:Enterprise” objects used in the mechanism of the complex periodic calculations. This mechanism can be considered as the multipurpose tool to solve the tasks of salary accounting of any complexity. In truth, salary accounting is the most typical implementation of this mechanism, but mechanism by itself has no orientation exactly on this task and has been successfully used to solve other tasks that require the description of periodic calculations with the complex interconnections, for example, the calculation of dividends, the cost of public services, etc. It has a set of standard strategies the example of which can be the exclusion of some types of calculations the other when they intersect on time scale. Subject to the task of salary accounting this opportunity solves all the complex of the problems associated with the intersecting on time scale charge and withholding for which the complex rules of mutual exclusion are defined. Another example is the ability to establish interconnection between different types of charge and withholding over an action period. Thus, the mechanism is a certain mathematic model which establishes the relations between different calculation types and provides the developer the mechanisms of information processing working on the basis of this model.
Without going into details of this mechanism, it should be noted that it allows the full description of salary accounting scheme base on the existing prototypes of application objects and opportunities inherent in them. By the example of this mechanism it is enough to clearly demonstrate the effect of the proposed approach usage. We have no information at this time about the presence of such mechanism in any tool of economic software development. In all known cases the module of salary accounting (Payroll) is implemented with fairly high costs for both design and implementation. Moreover, this module has to be substantially or completely rewritten for every country, as it is strongly associated with local legislation. Implementation of complex periodic calculation mechanism in “1C:Enterprise” allows transferring the development of such module from design “from scratch” to implementation by the standard scheme. According to our assessment it reduces the costs ten times, but most importantly, making changes is significantly simplified during system support.
Another typical example is the mechanisms of characteristics designed to solve the tasks that do not agree well with classic relative database model. One of these tasks is the structure construction for representing the various properties (characteristics) of commodity classification and list of products. If solution is created for a single organization with well-defined orientation on a specific commodity group, then all necessary requisites can be inherent directly in the structure of commodity catalogue. For example, the dealer firm of selling the cars it will be the color, engine displacement, etc. But if the production business application or solution for organization is created which products or sells a various nomenclature, this is not an option since it is obvious that the characteristics composition should depend on a particular nomenclature group and the addition of each new group should not be accompanied by a solution redesign. It is clear that implementation of such solution fits hard with the relative structure and requires special approach. Implemented in “1C:Enterprise” mechanism of characteristics provides the developer the typical tool to solve the similar tasks. The specialized prototype is designed to organize the storage of list of characteristics types. Meanwhile, each such type is associated with its own data type. For example, the engine displacement will be specified by number, and color will be chosen from manual. It is important that the particular types of characteristics can be not only determined in the application, but also be added by the user during system operation without changing application solution. In this case the developer can use this mechanism in a variety of operations, for example, to store the logically connected combinations of nomenclature characteristics and calculate the cost price subject to the existing combinations.
One more interesting solution is the mechanism of business processes (work-flow) that allows the developer to organize the simultaneous user work during execution the typical sequences of business transactions. In many existing information systems to solve the tasks of work-flow the specialized products are used which should be integrated with the applications solving the economic tasks. In “1C:Enterprise” platform the mechanism of business processes is fully integrated in the system so that neither the developer nor the user sees “the seams” that separate this mechanism and other functionality. This mechanism includes the tools to describe in application solution the schemes of business processes, to form the tasks executing at each point along the route, to manage business process and organize its relations with the other functions of application solution. This mechanism provides developer the flexible opportunities of process branching control and task forming. For example, besides the usual conditional branching the developer can visually describe the parallel passing of several route branches and specify the point of their merging. It is allowed to send one task to a group of potential executors, for example, if one of the department managers should make out a check. Conversely, in some route point you can initiate several tasks, for example, if the financial reports should be introduced by all the department heads. Role-routing allows forming the task not only directly for a specific employee, but also distributing the tasks by the roles, units and other criteria which can be described by the developer of the application solution. During role-routing execution it is allowed to specify the current distribution of employees’ responsibilities subject to the time replacements, combination of multiple positions, etc. It is important to note that this mechanism proposes the ready strategy to automate the simultaneous activities of enterprise employees. To describe the simplest business process it is enough to visually specify the route scheme and define the conditions for branching in their node points. All other actions are executed by the system automatically. During the complex business processes execution the efforts of the developer are required mainly to their close link with the functions of application solution.
On these examples we have demonstrated that each prototype of application objects and combining them mechanisms solves a certain task domain of subject area with significant reduction of the costs for development and, most importantly, providing the standardization of application solutions.
To give a notion about the range of tools available for the developer we will briefly describe more several mechanisms below.
Thus, to solve the tasks associated with accounting the availability and movement of the assets (tangible assets and cash resources) the mechanism of accumulation registers is proposed.
It supports the multidimensional accounting system with an arbitrary combination of measures and resources and provides optimization of the results receiving at different points of time, thereby allowing effectively solving the tasks of materials accounting, production and financial planning, payments for partners, etc.
The accounting mechanism is a universal “engine” for solving the tasks of accounting automation in different book-keeping models.
It can be used in different countries and has a big reserve of flexibility for additional customizing. It is based on the principle of dual recording, and it is allowed the work with financial transactions (operations) including both the simple correspondences (one debit and one credit) which are accepted in the Russian accounting and in the accounting models of other countries and the complex implemented in most western countries (several debits and several credits).
The mechanism supports the multidimensional accounting system with the arbitrary composition of measures and resources. Its unique property is the ability to configure the composition of additional measures independently for each account. At the same time it is allowed to form the measure combination both by the developer during application solution creation and by the user during the system operation. The multilevel and multidimensional results in sections of the periods, cross-correspondences, etc. are generated automatically.
Information mechanism is designed to solve the tasks associated with the storage or different information about the objects in different sections.
For example, the data of the commodity prices can be stored in the section of their nomenclature, client categories, etc. If necessary, the storage of the history of the introduced changes can be supported that allows getting together with the actual data their values for any passed point of time. The mechanism provides all the logics to work with the stored information, from data handling to its automatic context representation in the user interface.
We emphasize once again that in “1C:Enterprise” model the application mechanisms and the their underlying prototypes are not simply the set of prototypes which the developer can use “as needed”. The entire application solution with the need is based on the use of the proposed set of prototypes.
This quite compact set is enough to cover all the needs of subject area. Having a set of prototypes the system actually imposes the developer the standard design model, and this allows, in our estimation, significantly reducing the costs for construction and maintenance of application solutions.
High-level interface model
It is obvious that for business application the question of user interface organization is of particular importance. Firstly, because for a substantial part of the users these applications are the main tool, and these users work with them most of the day not being often the professional computer users. Secondly, business application interface is usually very “solid”. Unlike many other system classes the business applications typically contain from a few hundred to several thousands of forms. Besides, these forms can periodically change, for example, during system development or when it is necessary to change the business logic. Of course, the costs for application solution interface development are very high. That is why “1C:Enterprise” platform include a number of mechanisms oriented on the fast development of ergonomic user interface. They implement their own window model, the system of forms, the set of control elements, etc.
The main idea of interface construction implemented in “1C:Enterprise” is the maximal usage of information from metadata, as well as the objects of data handling such that the entire structure does not require the detailed configuration from the developer’s side and operated mostly automatically. We have already mentioned above that the objects of built-in language used for data handling are applied also for their representation in interface. It is enough for the developer to link this object with control element and the interface mechanism will completely take over the organization of data viewing and modification. However, the greatest effect is achieved by linking the data handling objects with the form itself, rather than the individual control elements. In this case all form functionality associated with data viewing and editing, as well as its connection with other forms is provided by the system automatically. For this purpose “1C:Enterprise” implements the mechanisms of the forms extensions and the control elements extensions. The extensions are automatically “included in work” subject to the data type with which the control element of the form is associated.
For example, the input box provides all the necessary actions for the reference value editing (selection from special forms, multiple selection, cleanup, highlight and automatic selection of the blank values, transition to the editing forms for the chosen objects, etc.). A so-called input by the line is very effective allowing speeding the mass information input by several times, eliminating the need to select the values from the list forms. For its implementation the list of the fields is defined in the propertied of metadata according which the users can quickly locate the necessary objects, for example, code, article, name. When typing several symbols the system automatically inserts the value of one of the defined metadata fields, which starts from the same characters. If there are several such values the user can select from the list. The developer in this case is not required any effort, because the interface mechanism is based on the metadata properties.
Another interesting example is the table field. This control element is a powerful mechanism of data visualization and editing providing the user the opportunity to view and edit the big lists using the dynamic reading. We have already mentioned above the mechanism of dynamic reading as one of the data handling tools. In interface mechanism of “1C:Enterprise” it allows you to view the data arrays of almost unlimited size without its entirely reading into memory. Meanwhile in terms of the user the list navigation does not practically differ from the viewing the data stored in the computer memory. This mechanism supports the flexible opportunities of search and filtering, viewing the hierarchical structures, editing the data in the list and individual forms, setting the columns composition and their sorting, printing the lists and their export in the different formats, etc.
For the forms, lists and other control elements the system automatically forms the command interface (buttons, menu and the entire control panels) providing all the actions for viewing and editing, as well as the relations with the other forms and service functions.
After describing the metadata object in application solution the developer may not build the form for it at all, all the necessary forms will be created automatically during the system operation. If he creates the form to define the specific properties for it, then the designer generates the standard form which does not contain any code on the built-in language, because the extensions of the control elements and the form provide all necessary functionality. Of course, the developer can without the designer insert in any form the control elements, link them with the data and get the completely working structure without writing a single line of code. He will need to append the code only when he will want to redefine or extent the standard functionality.
It is important that “1C:Enterprise” interface provides the operation of not only individual forms and control elements. The regular mechanics of application objects forms management provides a various options of the links between the forms used during value selection, multiple selection, information specification, etc. In fact, “1C:Enterprise” platform provides the developer the ready strategy of the entire interface organization for the business application which contains the methods of implementation practically of all necessary user work scenarios.
Through the use of the knowledge about the relations between the different objects stored in metadata the automatic generation of transition command between the logically linked forms is supported. Thus, the user working with some document without any efforts from the programmer’s side can get the access to the records representing this document in different accounting mechanisms. In addition the links defined in metadata by the business logic of the application solution, the developer can define (as the selection criteria) the additional relations for transition between the objects which will be represented also automatically in the command interface of the forms.
Another standard interface solution is a so-called mechanism of “the input for the reason “. it allows during data input for on object to fill automatically a number of the fields extracting their values from data of the other objects. For example, making out the check the user can form the pressing one button invoice based on this check: for this purpose it is enough to establish in metadata the relation between the mentioned objects and describe the rules of the filed filling.
The developer of application solution is provided by the standard tool of the “changeable” command interface implementation. In the application solutions that have a large amount of functionality this provides the user the ability to switch to the other work mode with the full or partial change of the command interface without leaving the system.
The mechanism of the forms provides the strategy of semantic form identification allowing not re-open already opened forms, but activate the opened before forms when the user addresses to a particular information.
Thus, using the extensions of the forms and other mechanisms the integrated strategy of the user interface is supported which includes the different options of interconnection between the forms, automatic generation of the command interface for navigation by different system modes and functions, as well as all possible service modes providing the comfortable user work. We have already mentioned the “1C:Enterprise” interface implements may special elements that does not use the standard tools of operating system. This is done in order to construct the interface that maximally meets the specifics of business applications.
In particular, “1C:Enterprise” implements its own model of the window system oriented to work with a big number of heterogeneous information. For example, window maximization is managed by the user for each form separately, rather than a single mode for the entire application (like it is accepted in the standard MDI applications). In addition the traditional window types it uses the attached and hiding windows. “1C:Enterprise” allows calling from the modal window the non-modal windows so that, in fact, several layers of the multi-window interface are formed. The developer can open any forms modally without changing the logic of their work.
The automatic mode is supported for adjustment the sizes of the control elements when changing the form sizes and moving the separators inside it. Thus, the user can define the desired sizes for each form and its individual parts, and the forms automatically use the available space for effective displaying information. It is important that this mechanism does not require any configuration from the developer’s side, but admits, of course, more delicate tuning.
The forms and control elements have the design oriented on the one hand to display the maximal amount of information, and on the other hand to reduce the fatigability during the long user work. For this purpose the “flat” interface design is close to Web-design. To manage the interface design the mechanism of styles is provided which allows the centralized modification of the general view of application solution. Practically each control element “is equipped” by functionality oriented to economic tasks specifics. Besides, a number of control elements are provided which are directly aimed at the analytical tasks, such as a chart, Gantt chart, etc.
The interface mechanisms of “1C:Enterprise” have a lot of interesting elements, we have listed only a few solutions above. It is important that the entire set of interface mechanisms is provided for the developer in fairly high-level concepts. As already mentioned, an important quality of development concept in “1C:Enterprise” is the isolation of application solution from various technical details. For example, the developer has no access to manage the mouse movement or detailed drawing of the control elements. Even fairly complex mechanisms are provided for the developer in such way that on the one hand they can operate without any configuration at all, and on the other hand – provide the ability to set up in the simple high-level categories that do not require the special knowledge. Thanks to this the application solutions support the modern full-function interface, and at the same time only slight part of the source code is associated with its visual part and the most part implements the business logic of application solution interface.
It is necessary to mention about Web-extension – the mechanism that allows implementing Web-interface for the “1C:Enterprise” application solutions. We will not talk about the details of this mechanism technological layout. The most interesting in its implementation, in our view, is the fact that it maximally uses like the main (rich) interface for automatic generation of Web-forms information from metadata, as well as the knowledge about the purpose and structure of application objects prototypes. The form for editing any object or viewing the object list is created with Web-extension automatically or can be defined by the developer manually in the project. If the developer describes the form himself, then at his disposal there are the specialized control elements which not only allow establishing the link with particular data, but also provide all necessary functionality for viewing and editing. For example, the input boxes support the selection from the list forms and selection by the first letters, the lists support the hierarchical viewing, setting up by the user the filtrating and sorting. The system provides a rich set of standard actions for data “maintenance” and links the application forms by itself. Thereby, the uniformity of two versions of user interface is provided (of course, adjusted to the specifics of Web-environment), as well as the maximal automation of its development based on the usage of metadata information.
One of the most important, in our opinion, consequences of user interface construction based on the standard tools provided by the platform is the fact that the interface for all application solutions of “1C:Enterprise” is constructed uniformly. This allows the users to maximally use a previously accumulated experience. Having mastered the work techniques with the interface of one business application, the user will easily work with any other “1C:Enterprise” application solution.
Intelligent reporting mechanisms
Any business application has two main mechanisms that provide the user interaction with the system. This is an interface designed to enter information and the reporting tools. Since the mechanisms of report receiving are responsible, first of all, for providing the user information needed for administrative decision-making, of course, in “1C:Enterprise” they receive the special attention.
The reporting technology applied to “1C:Enterprise” contains, in our view, a number of unique solutions that have no direct analogues in other products. First of all, it should be noted that “1C:Enterprise” platform has no typical for most systems individual tool “report generator”. For report preparation the developer is provided by a number of mechanisms which can be used in different combinations and in conjunction with other mechanisms. Thank to this in “1C:Enterprise” the reports fit seamlessly in the general application interface. In fact, the user during operation does not see the distinction between the general interface and reporting mechanism. In our opinion, it should not be otherwise in the modern economic application system because analytical information can be used in all modes and forms, and the reports are generated mostly not for their printing, but the interactive analysis. That is why the reporting tools in “1C:Enterprise” are closely integrated with other mechanisms and have the powerful opportunities for interactive work.
One of the most interesting mechanisms of this kind provided by the platform is a report Builder that provides the ability to get the report with developed functionality with minimal efforts.
We wanted to ensure that the developer or the user briefly described which information it is necessary to analyze, and all the rest necessary to get full-functional manageable report the Builder would do by itself.
The selection of source information is conducted based on the descriptions executed using the query language of “1C:Enterprise”. As in this case the ready virtual tables of the accounting mechanisms are actively used, the query text for a rather complex report will take only a few lines. It is not necessary at all to write it by hand. In most cases the query is generated by the tools of visual designer and often all the procedure adds up to the choice of data source and definition of the result fields. This instrument provides a visual generation of logical constructions of almost unlimited complexity, including query unions and embedded queries, as well as is able “extract” the query text for editing which is located in any module place.
Based on the comprehensive analysis of the query text the Builder generates by itself all infrastructure necessary not only for reporting but also for its delicate configuration by the user, as well as navigation between the reports. As a result, the form is created containing both the report itself and the various tools of its management – selection the fields included in report, information filtering according the complex criteria, grouping by the rows and columns, data sorting settings, etc. The report can be displayed as a table multilevel hierarchy of the rows and columns, as a chart, summary chart or summary table.
Note that the interactive filtering setup provides such features as setting the selection by the fields of related tables (obtained “through the point “), indication as a selection criterion the set of the values and object groups from the hierarchy of which information should be collected. For example, the user can configure the report of purchases of goods so that it includes only the invoices containing the goods which manufacturers refer to the groups “Native” and “Foreign”. In this case the Builder allows saving the current user report settings for future work.
In addition, the Builder automatically includes in the generated report all information necessary to decrypt the individual report cells (drill-down). This decryption is carried out in interactive mode – just one click on the selected report cell can automatically generate more detailed report based on this cell data and information contained in the source report:
It is very important that all these possibilities provided to the developer in a finished form can be used by him in different combinations. As a result, he can flexibly define for each created report what “degrees of freedom” to give the user, indicating this in the query text. For example, you can specify by which fields the user can set the filtering, sorting, grouping, etc. The elements of report management are included in the form also at the developer’s option. Since all the components of this mechanism can be used independently, the developer can apply the Builder not only for report preparation, but for solving many other problems. For example, he can create the procedure of the group data modification in which to manage the data selection all the Builder mechanisms will be used, but then the received sample will not be displayed in the report, and will be processed, for example, for selected group of goods the prices will be adjusted.
Also a very important effect of this mechanism usage we believe the fact that on its basis in “1C:Enterprise” application solutions the tools are implemented in which the “advanced” users can actually create by themselves rather complex reports. On the basis of this mechanism the special report console is constructed used in the most application solutions, which provide the user the ability to design his own reports, generate them immediately, configure and even created the system of connected and detailing each other reports. The questions of drawing tools effectiveness were not forgotten. In “1C:Enterprise” for report visualization and printing a metaphor of tabular document (without calculating tools) is primarily used. The basic idea if this solution is the use of spreadsheet model as a means of report documents design without its usage as a calculating tool.
Unlike the most spreadsheets the tabular document of “1C:Enterprise” may contain the tables with a very big sizes both vertically and horizontally. It has a rich set of visual features allowing on the one hand to created a well-designed analytical reports, an on the other – to prepare the regulated blanks with the exact referencing of the objects contained in them to the local coordinates. Unlike the standard spreadsheets here it is allowed to describe the lines with different settings of column width. It is necessary to create the complex reports including several multi-format tables.
In most cases, the report filling is carried out based the prototype. For this purpose the tabular document provides the flexible system of naming fields and parameter descriptions. The developer visually designs the prototype that defines the report’s appearance by highlighting in it different areas, which should be filled by data, and describing their parameters. During report generation the combination of the fields with data is executed, and so the content part of report is united with is external design. It should be noted that the report prototype can be created both by the Builder automatically and the developer. It is allowed to use the ready styles for report design and design own reports.
It is important that the means of tabular document generation serves not only for receiving the static printing forms. It has a powerful interactive mechanism to manage the multilevel groups, decrypt the report cells (drill-down), auto-tuning the column width, etc. It is allowed to save the report in different formats (html, xls, txt). In addition, for interactive analysis of multidimensional information in tabular document the summary table can be used that allows you directly managing information grouping and structure of displayed data without updating the report.
An extremely important feature of tabular document is the ability of its usage as a full-functional mechanism of information input and editing. Such document can contain any control elements used in the “1C:Enterprise” forms both in the cells and figures and over the cells. This is particularly useful in those cases where the same form should be a report and a tool of information editing. An example is the report of the planned indicators which is allowed to adjust.
For visual representation of analytical information the developer is provided by the set of various kinds of the chart, as well as the Gantt chart, summary chart and dendrogram. Moreover, these elements can be included both in the forms along with the other control elements and in the tabular documents for receiving the complex analytical reports.
The mechanism of data mining is also very useful through which the application solution can be equipped with the minimal costs by such analytical tools as cluster analysis, decision tree, etc.
An important feature of “1C:Enterprise” platform is that for generating the reports of any complexity the developer will not have to attach the additional external mechanisms. In this case all the internal tools are well integrated based on a single system of concepts and maximally use the abilities of each other. For example, the summary table contained in the tabular document to automatically modify the database query as fast as the user visually defines the new grouping level addresses to the functions of the report Builder. Of course, the system has the report Builder which provides their interactive design, but it is important that the Builder only “collects” the report from the existing mechanisms (“cubes”) applied also to solve many other tasks. As practice showed, in this approach the development of a fairly complex report takes no more than a few minutes.
Construction of distributed and integrated information systems
Another “trump card” of “1C:Enterprise” platform are the mechanisms of data exchange.
Initially, the decision to create the data exchange mechanism designed for geographically distributed information bases and not required a permanent connection was conditioned more by the lack of available domestic enterprises of qualified high-speed telecommunication channels. However, some time later it became clear that the development of such mechanisms is in the tideway of one of the most promising directions of world engineering idea.
Today at the disposal of the application developer there is a powerful set of exchange mechanisms able to solve a variety of tasks. In addition to the traditional support of geographically distributed information systems, with its help the integration with other applications is conducted, as well as the complex heterogeneous information systems are constructed which include along with the solutions on “1C:Enterprise” platform the external applications.
The use of exchange technologies for solving such a wide range of tasks is explained by the fact that at the disposal of developer there is not a monolithic solution, but a set of mechanisms that can be applied both separately and together in any combination. These mechanisms support the work with XML documents, XML-serialization of data, message infrastructure, changes registration service, exchange plans, management of distributed information base:
Almost unique, in our opinion, quality of this set of mechanisms is that it provides a very high level of system availability to work in the distributed environment – exchange organization practically does not require the additional costs for development. It is necessary just to specify in interactive mode the composition of data involved in exchange, and mechanism will provide the generation of messages and their loading. In this case the system automatically organizes exchange of only modified information, monitors the message receiving, determines the need to resend the data, solves the collisions and checks the integrity of loaded information. The flexible configure opportunities allow generating practically any topology of exchange nodes scheme (star, snowflake, schemes without central node). The data composition involved in exchange and the rules of collision solving can be specified arbitrary. In this case the exchange mechanisms on the one hand minimize the volume of transmitted data (only modified data is transmitted), and on the other – ensure the resistance to the loss of messages. In other words, the system can operate both in conditions of guaranteed message delivery and without it.
The presence in platform of effective exchange mechanisms which do not require the complex configuration owes, first of all, to the general architecture of application solution construction implemented in “1C:Enterprise” platform. We have already mentioned that the seamless transition to the distributed and integrated systems is provided by the object technique of data handling used in “1C:Enterprise”. The system of corresponding objects provides the regular opportunities for saving (persistence) any application data in XML format. In addition, thanks to the availability of standard prototypes of application objects the platform is able to automatically specify for each object the necessary granularity to transmit the changes and the exchange strategy according its purpose. The main problem of the most known systems of exchange and replication is that the semantics of data description embedded in them does not contain information about what portions to perform the exchange, how to solve the collisions, how to provide the logical integrity and consistency of data. Because of this, the developer usually has to describe the exchange procedures for each information array when using such mechanisms.
The exchange mechanisms of “1C:Enterprise” operate at the level of standard prototypes of application objects and therefore have initially at their disposal all necessary information of such kind. The developer only needs to specify that the objects of particular type are involved in exchange. Further, all the actions of registration the changes, message generation, data loading and collision solving will be executed automatically. Of course, the developer has the ability to perform manually “the delicate configuration”, but it will be necessary only in individual cases.
Another important feature of “1C:Enterprise” exchange mechanisms – their correspondence to the advanced world concepts of information systems integration. We understand very well that today no on economic software developer can consider himself “king of the hill” who do not have to worry about the close interaction with the system of other vendors. In this context the interaction is not only the ability to call some function from other program or export to it some data. It is about construction of the complex heterogeneous systems in which several heterogeneous application solutions form a consistently functioning ensemble. It is obvious that this trend will become in foreseeable future a dominant on the economic system market. The “1C:Enterprise” exchange mechanisms have a high availability to work on heterogeneous systems of today and tomorrow, not only due to the fact that all the exchange is performed in XML format, but, more importantly, because of the ideological correspondence of implemented solutions to the specified trend. Already today the exchange mechanisms of “1C:Enterprise” allow performing the interaction not only with individual applications, but also with advanced integration platforms.
Delivery and update of application solutions
Almost all application program manufacturers provide in them the mechanisms to update the versions. However, for such system as “1C:Enterprise” these tasks have a special challenge. This is because, firstly, the economic systems are updated more frequently then others, and secondly, the modification of application solutions of “1C:Enterprise” is in use other enough “on the ground” in order to adopt the canned product to the demands of particular user. The last feature has a special challenge, because when the developer releases any update for application solution it is necessary to synchronize the modifications he made to those that have been made during the introduction for the customer.
To solve these and many other tasks associated with delivery and update of application solutions “1C:Enterprise” has implemented a set of mechanisms oriented both to the developers and the users. They cover all technological process of delivery and support: preparing of distributive files, incremental updates and delivery installation kits, publishing the updates in Internet, their automatic search and execution, managing the support composition at the level of configuration objects, etc.:
One of the most significant elements of updating technique is mechanism providing the synchronization of changes made by the supplier of application solution with the changes made during introduction on a particular enterprise. It provides the powerful functions of comparison and analysis of the changes, as well as the tools of their synchronization management. The administrator or developer can set up in detail the synchronization of the changes up to the individual objects, individual features and individual procedures of the modules. For example, if the specialist responsible for maintenance of application solution on enterprise will mark the objects which he is going to maintain by himself they will not updated further when installing another update from supplier. If it is necessary to merge the objects, then to simplify the synchronization of the changes you can customize the priorities of such merging.
The updating mechanisms allow constructing the complex multilevel system of maintenance. The suppliers of specialized vertical solutions can be supported by the developers of universal applications and provide, in turn, the support of their own customers. In this case, the user will exploit the application solution the individual parts of which are accompanied by different companies.
Since the updating mechanism is substantially based on the fact the entire application solution is described with metadata, and business logic is constructed on the standard prototypes of application objects, the system is able to support the updating strategy subject to architecture of application solution, to control its logical integrity and provide the user information about the changes in visual form.
It is allowed to implement the entire interface of application solution on several languages. Each user can work with one of the languages embedded in it. In this case it is not necessary to move all the lines in separate files. The interface elements are edited in several languages “as applicable” – in the forms, the print document prototypes, menus, etc. The developer can switch at any time and edit the interface of the forms in other language. It is also possible an alternate editing of particular label in all supported languages. If it is necessary to extent the language base, you can collect all text elements in common list in order to display the translation of the same labels in all interface components at once.
The general strategy of internationalization includes also the system interface translation, storage of all lines in UNICODE coding, formatting dates and numbers in accordance with the characteristics of different countries and languages, construction of sorting rules subject to the national standards, etc.
Execution of business logic algorithms can be moved by he developer at his own discretion on the “1C:Enterprise” server. This allows him to manage the distribution of loading between user and server. In this case the developer does not need the special knowledge of three-level architecture construction, knowledge of network protocols, etc. All the technological details system takes upon itself and provides a rational use of server resources by supporting the stateless-model, caching and separating the system resources, etc.
In the system of access rights protection of “1C:Enterprise” the ability of configuring the restrictions is implemented at the level of individual records, as well as the table fields. This allows, for example, giving the user access to the employees names only within his department, and to the salary and marital status data – only for his direct subordinates. Configuration of such restrictions requires only specification of formal condition after which the system controls all the user actions automatically. The developer does not need to consider these restrictions explicitly during implementation of different interface mechanisms and business logic algorithms.
Two strategies of access rights check are provided. Depending the solved task the system of access rights control can both deny the user address to the data closed for him and simply delete unavailable records from the sample providing the user only available information.
One of the powerful tools of “1C:Enterprise” developer is the mechanisms of comparing and merging the application solutions. We have already mentioned about it when we talked about support possibilities, however this mechanism can very effectively used in the development process. This tool can be used both to analyze the differences and to transfer the part of function form one application to another. It provides a convenient visual representation of differences between application solutions and has the flexible opportunities to setup the comparison logic. When comparing the related configuration this mechanism automatically maps even the renamed objects using for this the internal metadata identification. The correspondence of compared objects regardless the coincidence of their names can be configured manually too, after which it will be taken into account in all references of such objects contained in the other objects of application solution. In addition, the comparing mechanism contains the tools of visual representation of the differences for interface forms and printing document prototypes. Thanks to the usage of metadata structure and the tools of visual comparison of interface objects, using our platform you succeed in solving much more tasks than in the systems where the comparing mechanisms are based on the comparison of the source code files of the programs.
“1C:Enterprise” supports logging the user actions in the log file. The system has several logging levels that can operate automatically not requiring the additional efforts from the developer’s side. First of all, of course, the start and end of user sessions are captured, as well as administrative operation with information base and the registered errors. Due to the fact the all the changes in DB are performed exclusively in object technique (through the objects responsible for the data handling), the system can automatically register them in log file and will do this regardless of whether they were executed (interactively or programmatically). The developer can also implement adding in log file any other records which the system is not able to capture automatically, for example, information of fax sending or report generation. It is important to note that the log file is implemented as a separate system mechanism. It does not use to store information the “1C:Enterprise” database and, therefore, his conduction does not create a significant additional system load and does not slow down the user work.
Summing up the results
In this article we tried to list the most interesting technological innovations of “1C:Enterprise” platform. Meanwhile we tried to show that all solutions implemented in it are based on the usage of a single model and a single architecture.
It is also important that all platform mechanisms use more or less the opportunities of other mechanisms. For example, almost all of them are based on the metadata structure and the presence in the system the application objects prototypes. Thus, although each of “1C:Enterprise” possibilities can be quite valuable by itself, the most interesting is consideration of their entire collection within integral model.
Let’s formulate one more time some general principles underlying the “1C:Enterprise” model:
The platform architecture and its instrumental tools are implemented so that the developer of business application can concentrate on solving the application tasks in his subject area maximally abstracting from the low-level technologies.
All development from data structure construction to interface elements design and integration tools connection is conducted in a single system of the concepts that significantly speeds up the specialists learning and increases their productivity.
The platform contains the ready questions almost for all questions appearing from the application solution developer, starting from how to display in information base the subject area data and ending the procedures of delivery, support and administrating. Or course, the developer does not have to learn various technologies and to solve the questions of their joint use.
The presence of a single, end-to-end high-level model and the technologies which implement it allows, in our judgment, reducing the cost for creation and support of application solution ten times.
Starting the works in this direction in 1996 and even releasing the first platform version, we were absolutely sure, of course, in the correctness of the chosen way. Over the past since then, the system conception was successfully developed, and today it is embodied in “1C:Enterprise 8” platform. Strictly speaking, there are not so many specialized technologies in the world oriented precisely on the fast creation of business applications. However, it becomes more obvious that this way lies on the strategic direction of business software development.
According the evaluation of many specialists with whom we had to communicate, the situation if Russia and the countries of the former Soviet Union, where there was a whole industry of business solution development and maintenance based on the specialized technological platform, is a unique according the world measures. According to our observations, there is no similar specialized platform on which various companies have created so many different mass business applications that cover the demands of significant part of market for any region. Naturally, for many specialists our approaches and solutions are of particular interest because the real effect of their implementation is well noticeable in practice.
Of course, all stated above considerations (including analysis of the modern trends) are only our position and the result of our investigations. We do not pretend under any circumstances on absolute truth which apparently does not exist in these questions. Certainly, many readers have their own, different from ours point of view on the problems raised in the article. We will be grateful for feedback (including critical) of this article.