Setting up and Preparing the configuration

"1C:Enterprise" Mobile client

General information

This section contains information that should be considered when developing applications running in a mobile client.

It is commonly known that an application on a mobile platform contains a copy of the used configuration and operates only with it. At the same time, the mobile client should operate with the version of the configuration that is currently in the Infobase to which the mobile client is attached. However, application stores may require that an application published in a store does not change its functionality after installation on a user's device. In a sense, these requirements are mutually exclusive.

In order for the mobile client application to be published in the application store, several requirements must be met:

The mobile client can operate only with those configurations that are specified before assembly. One mobile application can manage several information bases.
Each configuration has its own electronic signature (including the configuration metadata characteristic), due to which there is no option of a complete replacement of the configuration in the Infobase.

Compliance with these requirements allows the assembled mobile client application to be published in the application store and meet the requirements of this store.

The mobile client interacts with the Infobase via HTTP/HTTPS. This means that the mobile client does not support direct connection and can operate only with the information bases that are published on the web-server. When operating with the mobile client, it is not required to ensure exact correspondence between the mobile client version and the web-server or 1C:Enterprise server extension version. Compatibility is provided not within the version number of the 1C:Enterprise system, but within the version of the interaction protocol. In the event that the interaction protocol is substantially changed, it will be necessary to update the thin client application on mobile devices.

Unlike an application on a mobile platform, which, in fact, is an individual and separate application, an application for a mobile client is an adaptation of an ordinary application that runs in a thin client or a web-client. But for the correct operation of this application in the mobile client, the platform needs to “prompt” how to build the interface in the mobile client. The properties of the form elements are intended for this.

Preparing the configuration for operation in the mobile client

In order that configuration will be able to operate in a mobile client, you need to perform some set of actions:

Set the Compatibility mode configuration property in the Version 8.3.7 value and later.
Perform adaptation of configuration forms, taking into account the peculiarities of displaying these forms on mobile devices.
In the modules with 1C:Enterprise language, use the compilation directive # If NOT a MobileClient Then ... # EndIf everywhere where you want to mark the code that can only operate on a mobile device.
Generate a digital signature for the configuration.

Digital signature and configuration digest

As already mentioned, the mobile client application cannot arbitrarily change its functionality after downloading it to the user's mobile device. Such a requirement is imposed by the application stores on the mobile applications which download their code from the external resources. To comply with this requirement, each configuration that can operate in the mobile application contains some auxiliary information that allows tracking a considerable change in the configuration.

The scheme of operation is as follows:

At the beginning of the development of the configuration (in the configurator) a private key is generated to form the signature of the configuration being developed.

IMPORTANT! Each configuration must have a unique private key. Using the same private key for multiple configurations ‑ is not allowed.

Configuration development in progress.
If it is necessary to publish the configuration, a configuration signature is generated in the mobile client. When performing this action, a configuration digest is created, which is signed by the private key.
When uploading the configuration for the mobile application builder, the public key (for the private key use) is placed in the file, with which you can verify the digital signature.
The builder places the public key in the assembled mobile client application.
When attempting to connect a mobile client to an Infobase, the 1C:Enterprise server passes a digital signature of the configuration and the current configuration digest to the mobile client.
A mobile client is connected, only if configuration name (Name configuration property) is not modified from the date when the mobile application is built and a digital signature used for that purpose corresponds to the digest so transferred. This can be verified because the mobile application contains the public key with which the verification is performed.

IMPORTANT! The private key is confidential information.

When you use iOS mobile application home page to add an information base, the compatibility check is based on the digital signatures of all configurations included in the mobile client application build.

In the event that it is necessary for the platform to automatically check the configuration and the created digital signature, open the dialog box Main menu ‑Configuration ‑ Mobile client ‑ Setting the use of the mobile client. In the dialog box, select the Check mobile client signature checkbox when updating the database configuration and click the OK button. After that, when the Update database configuration command is executed, the compliance of the saved configuration and the existing digital signature will be checked.

The configuration digest is designed to test the feature of the mobile client to operate with the Infobase to which it is attached. The configuration digest includes the following information:

The name and internal ID of the following configuration objects:
- Catalogues;
- Documents;
- Charts of characteristic types;
- Exchange plans;
- Enumerations;
- Business-processes.
Names and components of the write keys for the following configuration objects:
- Information register;
- Accumulation registers;
- Accounting registers;
- Calculation registers.
The extensions used by the configuration are not included in the digest components.

A change in the configuration objects included in the configuration digest means the necessity to resign the developed configuration.

Thus, the actions necessary in the case of the configuration change are divided depending on the further development of the mobile client configuration:

Configuration author: in the case of the configuration digest change, it is necessary to resign the configuration without changing the published mobile client application. The mobile client application does not need to be republished in this case.
Other experts without access to the configuration private key. One of the following actions can be performed in this case:
- To ask the original configuration developer to resign your copy of further developed configuration.
- To build (with the help of the mobile application builder) and publish your copy of the mobile application intended for the further developed configuration exploitation. The opportunity to work with the original configuration can be saved in this application. Do not forget that, in this case, the publication in the mobile applications store will be performed on behalf of the company which has further developed the configuration with all consequences (registration as the developer in the application store, certificates, etc.).

Thus, the use of a new private key to sign a configuration automatically means that such configuration can be used only with the mobile application which has the public key for the digest validation. So, the mobile application shall be updated before the undated configuration becomes accessible in the used information base.

Operation with data associated with the current row of tables

In the event that there is data on the form associated with the current row of the table (one or more), then it is recommended to do the following:

All form data associated with the current table data should be divided into groups so that one group displays data associated with the current row of only one table.
For each such group, you should set the properties Usage of the current row (CurrentRowUse) and Used Table (AssociatedTable) by analogy with the command form. It follows from this that one group can display data of only one table. That is why the above is a recommendation to place related data in different groups by the number of tables used.
For tables that are used as data sources for ancillary data, set Usage of current row property to Selection value.

In the mobile client on the form, there will be no groups for which the Use of the current row property is set to the Use value.

In order to see the associated data, you need to open the context menu on the selected row and select a command, the choice of which will open the data window. The team name is generated as the name of the hidden group. If in this table the current data is displayed in several groups, ‑ the name of the command will be generated from the headings of all groups, combined by the symbol «,».