It is essential to decide how we handle data within business applications as this determines the architecture of the software. One way or another, every application is built around data. And while in some software data plays an auxiliary role, in business applications it becomes the core.
This article will not touch upon technical aspects of data storage and handling but consider how data representation impacts application design. Why is data so important in business applications?
Because data is used to describe a subject matter. We need to know entities relevant to a particular business and how they relate to each other. And data serves this purpose very well. Still, as we design an application, we are not aiming to pick all data available. What we need are task-related entities with their relations, plus some extra for future development in directions with good potential. Say we want to automate staff development process. In this case, we collect data on education and employment history, while shoes and clothes size data is left unattended. On the other hand, if we aim is to automate workwear management, this becomes relevant. I assume that a curious mind will be unwilling to stop even here. With staff development comes motivation. Motivation creates a place for corporate workwear, and so on. As you can see, data is practically limitless, and the art of application design depends only on the art of data modeling.
Still, it is no doubt that processes play a significant role in business applications. As well as other developers of business application platforms, we tend to believe that processes have a major impact on application design. Nevertheless, the importance of data cannot be underestimated. It is the approach to the presentation of data that determines how an application will work.
Still, I need to mention that by data we mean actual data plus associated processes. Thus, processes, though indirectly, are still present in a data model.
1C:Enterprise platform offers tools to work with processes directly, but this is a subject for another article.
There are several approaches to data processing.
To begin with, it is a classic relational model. Data is presented in relational tables (usually stored in a relational database management system). This approach is far from being new but remains relevant.
Another approach is object-oriented programming. Data is treated as a programming language object and is stored in a database. This can be either a relation or an object-oriented one. In the first case modeling is governed by DBMS, while in the latter, it is ORM that comes into place.
In addition to these two approaches, some other methods and solutions are utilized in designing business applications. Semi-structured data approach is among them.
Now we are getting to the approach we have chosen for 1C:Enterprise platform. It has no universally recognized name, and we chose to call it applied object type model. The key concept is that the platform contains a number of applied object types. These object types describe specific categories of subject-related entities within an application model. Designers need to use suitable object types to describe a data model adequately. By doing so, they present not only the data model but mostly the application model itself. We will pay a bit more attention to it a little later.
So what is meant by applied object types?
You can treat it as a preprogrammed template (or an abstract class) that defines multiple aspects of how the platform handles subject-related entities.
Applied object types are used both during design-time and run-time. In design time this will be either a meta-model to describe objects through metadata or entity classes to handle data within a program model. In run-time these will be the rules that determine how the system will handle an object. The lock engine mechanism is a good example here.
We use several applied object types in 1C:Enterprise.
We’ll take three of them:
Catalogs store static content (lists of employees, goods, and clients).
Documents contain events related to particular subject matters (sale, admission to job, bank transfer, and so on). Sometimes they are named as print forms like Payment Order or New Hire Form. But this is just for the sake of convenience. In fact, this is an event type and not a print form.
Accumulation Registers serve for accounting purposes, like the accounting of cash assets or warehouse inventory.
Now we can have a closer look at the set of features offered by applied object types.
Applied object types describe a data model and place data within a relational model. But this is just a smaller part of a bigger picture.
Thus, with catalogs we can:
utilize standard attributes (fields) that are built into the platform (reference ID, code, description, link to parent in hierarchical catalogs, etc.)
add our own (optional) attributes (fields)
- describe tables treated as containments (also called nested tables).
Documents are about the same, but here we have “Date” standard attribute that places an event on a timeline and “Posted” flag to show whether a document is registered in the system or still remains in draft state.
Accumulation Registers have dimension, resource, and attribute fields. Dimension describes accounting model designation (goods, warehouse, etc.), resource refers to values (amount or quantity), while an attribute is simply an optional field for comments and has no impact on the model.
So why do we use applied object types instead of tables or simply entities?
It is a good question. Tables offer plenty of advantages. They are a better fit for simple relational models and do not suffer from limitations imposed by predefined types. On the other hand, tables lack features granted by our platform.
The key benefit of our approach is that the platform so to say “knows a lot” about objects and “can do a lot to them.” With this knowledge and ability at hand, the system automatically engages dozens of mechanisms that work with objects both directly or indirectly. As soon as developers pick an object type and describe the object, the system can instantly use this information to initiate plenty of valuable tools and mechanisms. The idea behind it is that we define general semantics on the level of an object type and then specify a particular object semantics by means of metadata via properties and designated models describing various aspects.
These are some mechanisms used by the platform.
- Storage of data in structures and automatic transformation of structures in case of data model change.
Use of object model classes to handle data (read, write, search)
Object-relational mapping mechanism
Standard data processing procedures, like automated numbering for documents, calculation of totals and balance per specific date and time for registers, and so on.
Role-based access control. As the system knows the object designation, it can determine applicable rights and permissions.
Visualization (interface). Again, as the system knows objects’ rights and designation, it automatically creates menu items to access corresponding object types, forms to view and edit them, as well as commands to allow interaction.
Data exchange. The platform, relying on data semantics, asynchronously distributes modified data between both single vendor applications (distributed infobase nodes) and multivendor ones (based either on 1C:Enterprise or other technologies).
Object and transaction locks. To properly set up an interlock system, you need to know both how data is to be used and how it relates to other pieces of data.
Detailing. A user can define additional fields if needed.
Automatically generated REST interface (per OData standard)
Data import and export in XML and JSON formats
Full-text search, data access logging, and similar mechanisms are available at all times and require no additional setup.
These are just some platform mechanisms relying on applied objects.
To some extent, the approach based on applied object types is equal to an aspect-oriented one. All features listed above are predefined aspects described as applied object types. But applied object types are not simply templates. Instead, they are more like parameterized templates, where parameters are defined with metadata. By selecting values in properties, developers adjust a template, thus defining how an object will act within specified conditions. Here is an example. To have the system automatically assign and control document numbers for a specific period (year, quarter, or month), you need to set up a document numbering period.
Applied object types contain data on the semantics of both entities and their interrelations. An excellent illustration is a standard connection between documents and registers determining how events are presented within an accounting model. With this connection established, the system will immediately create a relation between a document and relevant records in the register. At that, the records will remain in the system as long as the document exists.
Also, I believe it is good to mention some useful subject-related aspects.
For instance, you can enable hierarchy mode in catalogs with a single flag. At that, the system will support hierarchy catalogs everywhere, including user interface, reports, and object model.
Enabling “Hierarchy Catalog” in catalog properties will allow hierarchy catalogs everywhere, including user interface, reports, and object model.
In Documents you can consolidate several document types in a journal or apply continuous numbering within a period.
In Accumulation Registers the most important feature is an automatic save of calculated results and ready-to-use virtual tables to evaluate results broken by periods.
To put it simple, applied object types contain a majority of universal (standard) mechanisms that can be used to implement business logic in end-user applications.
As a result, developers use object types as Lego parts to build applications of their own. Apart from other solutions that contain “abstract” elements, we offer parts with a specific purpose in mind like “wheels,” “windows,” or “doors.”
Developers need “Catalog” type to create goods, employees, currencies, client’s catalogs, and “Document” type to create purchase orders, invoices, sales orders.
So why do we think this approach is good methodology-wise? All developers share a common set of concepts that help them better understand the nature of applications and simplify communication between each other. Even being new to a 1C:Enterprise project developers can immediately see familiar elements and quickly identify the role of objects within the system. Here is a good example. Registers used within an application clearly describe what the application is built for. With applications based on tables and classes, it is much more challenging to get the idea simply by looking at such structures.
But more important is that such an approach pulls together the language of developers and business people (or analysts). The importance of a language that both parties can equally understand is well described in Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans. Applied object types are easy to understand for non-developers, making it easy for analysts, customers, and developers to discuss project functionality. It is pretty common to have business persons or analysts with no experience in software development but capable of describing the task with 1C:Enterprise applied object types.
What else to say? Such an approach stipulates the ongoing evolution of the system. We add new mechanisms to the platform, and they are immediately ready to interact with existing objects (with no or minimum efforts on behalf of developers). Some time ago we introduced data changes history (or versioning) functionality. And data semantics stored in the system is sufficient to enable data changes history for a particular object. Should developers wish to keep an object history, a single flag is enough for the system to take care of everything from storing of changes to visualization of such changes in various reports. A bit earlier we had introduced standard REST interface (per OData standard), and all applications immediately received ready-to-use REST interface without any effort on behalf of developers.
So why don’t we complement our applied object types with common tables? Well… It is a good question. And we are still looking for the answer.
It looks tempting on the one hand. Seems to be a good solution for cases where subjects do not ideally fit into predefined applied object types. How much easier it would be with developers. We could say, “Here is your simple table. Do whatever you think fit.” But on the other hand, this will leave our standard mechanisms clueless. How will they pick a proper way to process data with no information of data semantics? Though, to some extent, you can work with it even now. Technically, we do this with external sources. But in this case, we stay limited to simple tables that contain no information on the subject. The system can process them, but some functionality will be lost.
Thus, for now, our decision is to avoid simple tables in order to retain the platform integrity and remain capable of adding new functionality based on data semantics. If existing features are insufficient to meet our needs, we will first seek to improve applied object types. Naturally, this is not a final decision, and we might get back to this discussion in the foreseeable future.
To crown it all, it is worth saying that applied object types are the foundation for platform features and the high level of abstraction our developers enjoy so much. This is precisely what makes 1C:Enterprise so different from other development environments, and this is one of the major keys to quick and unified software development.