First-time integration of the library subsystems into a configuration significantly differs from updating an integrated library. Generally, the library integration consists of the following steps:
- 1. Copying metadata objects from the library distribution file to the configuration.
- 2. Configuring the copied library objects.
- 3. Using the library objects in configuration development.
All functional subsystems included in the library are subordinate to the "Standard subsystems" subsystem in the metadata object tree. The subsystems designed for SaaS configurations are subordinate to the "SaaS" subsystem.
For first-time integration of the library, use the external data processor FirstSSLDeployment.epf. You can use it to select subsystems for integration while preserving their reference integrity, and exclude unused subsystems. To validate the first SSL integration or further library version updates, use the external report SSLImplementationCheck.erf.* It identifies a variety of common problems related to library integration (validation of type composition filling, checking whether required code fragments are present, and so on).
To quickly start the development of a new configuration based on the library, you can use the quick start guide containing only the essential list of actions required to start the configuration. See Using subsystems in configurations.
* In client/server mode, ensure that the user that started the 1C:Enterprise server has sufficient rights to run this report.
2.1. Copying metadata objects from the library distribution file to the configuration
First-time integration
To copy library objects to the configuration during the first-time integration, in Designer, click Configuration – Compare and merge with configuration from file. In the dialog box, specify the library distribution file and confirm that you want to enable support.
Step 1. In the configuration comparison and merging window, clear all check boxes and select all objects to be copied using the Actions – Select by file subsystems command. In the Standard subsystems group, select the following:
- Required subsystems, as described in table 2.1.
- Additional subsystems required for configurations designed to run in SaaS mode, as described in table 2.2.
- Other subsystems to be integrated into the configuration.
- Subsystems required by the subsystems you selected, as described in tables 2.1–2.3.*
Click Install.
Attention!
Ensure that all required subsystems listed in table 2.1 are selected. If the configuration is designed to run in SaaS mode, the subsystems listed in table 2.2 are also required. Otherwise, the configuration will not work.
* To get the file with comparison and merging settings for this operation, use the FirstSSLDeployment.epf data processor.
Step 2. Select or clear the check boxes for individual library objects and their properties as described in table 2.5.
Next, click Actions – Set rule for all and select the Get from file merge rule, then click Execute. In the window with the list of dependent objects, click Continue.
Step 3. Once the comparison and merging are complete, the second stage begins: configuring library objects. See Configuring library objects. Depending on the number of subsystems, this step can take from one to several hours.
After you configure the library objects, it is recommended that you validate the integration using the SSLImplementationCheck.erf external report.
Updating library version
This section describes the general procedure of updating the library to a later version. Migration between library revisions, subrevisions, and versions (the first, second, and third digits in the version number, respectively) requires some additional actions, while migration between library builds (the fourth digit in the version number) generally requires no additional actions. Rarely, additional actions are required even when updating to a library build. Instructions for these situations are available in readme.txt (the Important section).
To update library version, click Configuration – Support – Update configuration. In the dialog box, click Select update file, specify the path to the library distribution file, and confirm that you want to update the vendor configuration.
Step 1. Some of the SSL objects referenced by the objects of your configuration might have been deleted from the new SSL version. To have these SSL objects deleted automatically, clear the references to them before the update. To find such objects in the configuration comparison and merging window, clear all the check boxes for metadata objects, then set the comparison and merging filter to Show objects available only in the old vendor configuration in the New vendor configuration – Old vendor configuration group as indicated in the picture.
Next, select the check boxes for all metadata objects, select the Get from new vendor configuration merge rule (Actions – Set rule for all), and click Actions – Find unresolved references to objects to be deleted.
After the operation is completed, a list of configuration objects that contain references to the SSL objects to be deleted is displayed. If there are any application objects in the list, remove the references to the SSL objects to be deleted from these application objects, and proceed to step 2.
Step 2. Run the Configuration – Support – Update configuration command again. Click Select update file and specify the path to the library distribution file.
In the configuration comparison and merging window, clear all check boxes and then select the objects to be copied using the Actions – Select by new vendor configuration subsystems command. In the "Standard subsystems" folder, select:
- Required subsystems, as described in table 2.1.
- Additional subsystems required for configurations designed to run in SaaS mode, as described in table 2.2.
- All previously integrated subsystems and other subsystems that you want to integrate.
- Subsystems required by the selected subsystems, as described in tables 2.1–2.3.
Click Install.
Attention!
Ensure that all required subsystems listed in table 2.1 and the related metadata objects are selected. If the configuration is designed to run in SaaS mode, the subsystems listed in table 2.2 are also required. Otherwise, the configuration will not work.
If the Administration subsystem was integrated or is planned for integration, in the configuration comparison and merging window, select the check box for this subsystem ("Administration" metadata object).
Click the Get from new vendor configuration merge rule (Actions – Set rule for all).
Additionally, select or clear the check boxes for individual library objects and their properties as described in table 2.6. Depending on the number of subsystems to update or install, this step can take from 15 minutes to one hour.
Then mark all obsolete metadata objects in the library for deletion. Set the comparison and merging filter to Show objects available only in the old vendor configuration in the New vendor configuration – Old vendor configuration group as indicated in the picture.
Then select the check boxes for all metadata objects and click Execute. In the window with the list of dependent objects, click Continue.
Updating to patches supports a greater degree of automation, resulting in significant time economy with regular (for example, weekly) updates. Library builds differ only in the fourth digit of the version number, for example: 2.3.4.1, 2.3.4.2, and 2.3.4.3.
For the purpose of updating to builds, use the external data processor UpdateToCorrectiveVersionSSL.epf.
Start the data processor in the infobase with the configuration containing the previous SSL release, click Update to corrective version, and specify the .cf file with the new SSL version from the distribution package. The configuration will be automatically compared and merged with the new library configuration using to the following rules: all supplied library objects will be copied and objects overridden during integration will be merged with the supplier’s configuration priority (for example, this rule applies to defined types) or skipped (for example, this rule applies to overridable modules). After comparison and merging, the database configuration will not be updated automatically, which allows you to run comparison with the database configuration and edit changed objects: overridable modules, local changes, and enhancements.
Alternately, click Generate a settings file to generate a comparison and merging settings file that can be imported into Designer for manual comparison and merging.
When updating to new functional releases (releases with the third number incremented), select the check boxes in the comparison and merging window in Designer, following the instructions above.
Step 3. Once the comparison and merging are complete, the second stage begins: Configuring library objects.
After you configure the library objects, it is recommended that you validate the integration using the SSLImplementationCheck.erf external report.
Library subsystem dependencies
Table 2.1. Subsystems required for integration
|
Subsystem |
Depends on |
|
Base functionality |
Security profiles (*) |
|
Infobase version update |
|
|
Users |
Contact information (**) |
* When integrating the "Base functionality" subsystem without the "Security profiles" subsystem, see the additional guidelines in the Special cases of integrating the subsystems section in Chapter 3.
** When integrating the "Users" subsystem into a configuration designed to run in SaaS mode, the "Contact information" subsystem is required. In other scenarios the subsystem is optional and can be integrated separately. For integration without this subsystem, see guidelines in the Special cases of integrating the subsystems section in Chapter 3.
Table 2.2. Additional subsystems required for configurations designed to run in SaaS mode
|
Subordinate subsystem in "SaaS" branch |
Depends on |
|
Core SaaS |
Data exchange Scheduled jobs |
|
Infobase version update in SaaS |
Closing user sessions |
|
Job queue |
|
|
Users SaaS |
|
|
Remote administration |
Table 2.3. Optional subsystems that allow selective integration
|
Subsystem |
Depends on |
|
Event log analysis |
Report options (*) Report mailing (*) |
|
Banks (**) |
Get files from the internet |
|
Currencies (**) |
Get files from the internet |
|
Report options |
Email operations (*) Attachable commands (*) Additional reports and data processors (*) Report mailing (*) |
|
Object versioning |
|
|
Work schedules |
Calendar schedules |
|
Batch object modification |
|
|
Period-end closing dates |
|
|
Additional reports and data processors (**) |
Print (*) Attachable commands Report options (*) Batch object modification (*) |
|
Closing user sessions |
|
|
Import data from file |
Additional reports and data processors (*) Batch object modification (*) |
|
Object filling |
Attachable commands |
|
Object attribute lock |
|
|
Calendar schedules |
|
|
Contact information |
Address classifier (*) Item order setup Attachable commands |
|
User reminders |
|
|
Item order setup |
|
|
Application settings |
All subsystems (*) |
|
Data exchange (**, ***) |
Configuration update (*) Get files from the internet (*) Object prefixes (*) Email operations (*) Scheduled jobs (*) |
|
Configuration update |
Closing user sessions Email operations (*) Software license check (*) |
|
Send text messages |
Get files from the internet |
|
|
Attachable commands Email operations (*) Stored files (*) Additional reports and data processors (*) |
|
Attachable commands |
Print (*) Report options (*) Object filling (*) Additional reports and data processors (*) |
|
Duplicate object detection |
|
|
Full-text search |
|
|
Get files from the internet |
|
|
Object prefixes |
|
|
Software license check |
|
|
Email operations |
|
|
Stored files |
Properties (*) Access management (*) |
|
Scheduled jobs |
|
|
Infobase backup |
Closing user sessions |
|
Properties |
Object attribute lock |
|
Hierarchy |
|
|
To-do list |
|
|
Deletion of marked objects |
|
|
Access management (**) |
|
|
Monitoring center |
Performance monitor (*) |
* Optional dependency, meaning that the subsystem can be integrated separately. Chapter 3 can contain additional guidelines on independent integration of the subsystem.
** When integrating subsystems into a configuration designed to run in SaaS mode, also integrate the subsystem with the same name and SaaS postfix from the "SaaS" branch. For example, when integrating the "Currencies" subsystem, also integrate the "Currencies SaaS" subsystem.
*** The "Data exchange" subsystem is mandatory for the development of data exchange in a distributed infobase.
Table 2.4. Optional subsystems that can be integrated into configurations designed to run in SaaS mode
|
Subordinate subsystem in "SaaS" branch |
Depends on |
|
Banks in SaaS |
Banks Supplied data |
|
Currencies SaaS |
Currencies Supplied data |
|
Additional reports and data processors SaaS |
Additional reports and data processors Supplied data Remote administration |
|
Supplied data |
Stored files |
|
Access management SaaS |
Access management |
|
File functions SaaS |
Stored files |
Objects and object properties to be selected or cleared before merging the configuration with the library
Table 2.5. Objects and object properties to be selected or cleared before merging the configuration with the library (during the first-time integration of the subsystem into the configuration)
|
# |
Object name |
Actions required |
|
For "Base functionality" subsystem |
||
|
Language: English |
Select the check box. * |
|
* If displayed in the metadata tree in the configuration comparison and merging window. |
||
|
Properties of the root configuration object:
|
Select the check box. |
|
Properties of the root configuration object:
|
Select the check box. * |
|
* When integrating the library without the "Stored files," "Configuration update," and "Infobase backup" subsystems, selecting this check box is not required. |
||
|
Other properties of the root configuration object |
Clear the check box. |
|
For "Application settings" subsystem |
||
|
Subsystem: Administration |
Select the check box (only for the subsystem, not for the subsystem content). |
|
Common commands:
|
Clear the check box. * |
|
* Only when integrating without the "Additional reports and data processors" subsystem. |
||
|
Common command: ReportsPanelAdministration |
Clear the check box. * |
|
* Only when integrating without the "Report options" subsystem. |
||
|
* Only when integrating without the "Object prefixes" subsystem. |
||
|
For "Attachable commands" subsystem |
||
|
Subsystem: AttachableReportsAndDataProcessors |
Select the check box (only for the subsystem, not for the subsystem content). |
Table 2.6. Objects and object properties to be selected or cleared before merging the configuration with the library (during the update of the subsystem in the configuration)
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
Clear the check box. |
Subsystems
|
# |
Object name |
Actions required |
|
"Application settings" subsystem |
||
|
|
Select the check box (only for the subsystem, not for the subsystem content). For the Command interface property, set the merge rule to Merge prioritizing new vendor configuration. For the Content property, set merge mode to Merge. |
|
"Attachable commands" subsystem |
||
|
|
Select the check box (only for the subsystem, not for the subsystem content). For the Command interface property, set the merge rule to Merge prioritizing new vendor configuration. For the Content property, set merge mode to Merge. |
Common modules
Clear the check box for all overridable common modules:
|
# |
Object name |
|
"Base functionality" subsystem |
|
|
|
|
All subsystems in the "SaaS" branch |
|
|
|
|
"Banks" subsystem |
|
|
|
|
"Report options" subsystem |
|
|
|
|
"Currencies" subsystem |
|
|
|
|
"Batch object modification" subsystem |
|
|
|
|
"Period-end closing dates" subsystem |
|
|
|
|
"Additional reports and data processors" subsystem |
|
|
|
|
"Object filling" subsystem |
|
|
|
|
"Object attribute lock" subsystem |
|
|
|
|
"Calendar schedules" subsystem |
|
|
|
|
"Application settings" subsystem |
|
|
|
|
"User reminders" subsystem |
|
|
|
|
"Data exchange" subsystem |
|
|
|
|
"Infobase version update" subsystem |
|
|
|
|
"Send text messages" subsystem |
|
|
|
|
"Print" subsystem |
|
|
|
|
"Attachable commands" subsystem |
|
|
|
|
"Duplicate object detection" subsystem |
|
|
|
|
"Full-text search" subsystem |
|
|
|
|
"Users" subsystem |
|
|
|
|
"Object prefixes" subsystem |
|
|
|
|
"Email operations" subsystem |
|
|
|
|
"Stored files" subsystem |
|
|
|
|
"Scheduled jobs" subsystem |
|
|
|
|
"Properties" subsystem |
|
|
|
|
"Hierarchy" subsystem |
|
|
|
|
"To-do list" subsystem |
|
|
|
|
"Access management" subsystem |
|
|
|
Roles
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
For the Rights property, set Merge rule to Merge prioritizing new vendor configuration. |
Common attributes
|
# |
Object name |
Actions required |
|
All subsystems in the "SaaS" branch |
||
|
|
Clear the check box. |
Filter criteria
|
# |
Object name |
Actions required |
|
"Hierarchy" subsystem |
||
|
|
Clear the check box. |
Functional options
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
|
|
|
|
|
|
|
Defined types
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
Clear the check box. |
|
"Base functionality" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Object versioning" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Period-end closing dates" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Additional reports and data processors" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Contact information" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Item order setup" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"User reminders" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Users" subsystem |
||
|
|
Clear the check box. |
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Stored files" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Properties" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Access management" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
|
Set Merge rule to Merge prioritizing new vendor configuration.
|
Common commands
|
# |
Object name |
Actions required |
|
"Data exchange" subsystem |
||
|
Command parameter type property:
|
Clear the check box |
|
"Hierarchy" subsystem |
||
|
|
Clear the check box. |
|
"Access management" subsystem |
||
|
3. |
SetRights, property: Command parameter type |
Clear the check box. |
Languages
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
1. |
English |
Select the check box. |
Catalogs
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. Internal IDs of predefined items can be changed without consequences (no data loss). For example, you can delete a predefined item and create a new one with the same name. The predefined item will be linked to a data item correctly. If a predefined item name (the full metadata object name without a dot) does not match an existing metadata object, this predefined item will not be linked to a data item and will not cause any issues. |
|
"Contact information" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Users" subsystem |
||
|
ExternalUsers, command: ExternalAccess, property: Command parameter type |
Clear the check box. |
|
"Properties" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
"Access management" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
Enumerations
|
# |
Object name |
Actions required |
|
"Send text messages" subsystem |
||
|
|
Clear the check box. |
Charts of characteristic types
|
# |
Object name |
Actions required |
|
"Period-end closing dates" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
|
|
Clear the check box. |
|
"Properties" subsystem |
||
|
|
Set Merge rule to Merge prioritizing new vendor configuration. |
Data processors
|
# |
Object name |
Actions required |
|
"Application settings" subsystem |
||
|
|
If forms were modified, clear the check box |
2.2. Configuring library objects
Right after the comparison and merging, the metadata objects are copied from the library to the configuration but not yet configured. To configure the copied library objects, follow the instructions in table 2.7.
If different actions are required for the first-time integration of the library and for the update of an already integrated library, the instructions in table 2.7 are divided into two sections: "First-time integration" and "Library version update." The root configuration object modules and overridable common modules require special attention because fully automatic update is not available for these modules. General instructions for the first-time configuration and update of library objects can be found after table 2.7.
Table 2.7. Library objects that require additional actions after comparing and merging the configuration with the library
Common SSL objects
|
# |
Object name |
Actions required |
|
Session module |
First-time integration:
|
|
Managed application module. Ordinary application module |
First-time integration: copy the code fragments marked with the following comments to the BeforeStart, OnStart, and BeforeExit handlers: // StandardSubsystems … // End StandardSubsystems Also copy the code fragments from the global variable definition area. Library version update: copy the global variable definition areas and the code fragments related to the integrated subsystems to the BeforeStart, OnStart, and BeforeExit handlers: // <SubsystemPath> … // End <SubsystemPath> |
|
Property: Version |
First-time integration: set the property according to R.S.V.B template, where: R is the revision number (1 or more digits). S is the subrevision number (1 or more digits). V is the version number (1 or more digits). B is the build number (1 or more digits). Example: 1.0.1.1. For more information, see Versions and releases numbering. Increment the version at each update. |
Common SSL objects for configurations designed to run in SaaS mode
|
# |
Object name |
Actions required |
|
Common attribute: DataAreaMainData |
First-time integration:
During each update:
|
|
Common attribute: DataAreaAuxiliaryData |
First-time integration:
During each update:
|
|
Common modules:
|
It is recommended that you follow the approach described in Configuring and updating overridable common modules of the library. |
|
Functional option: UseSeparationByDataAreas |
First-time integration:
|
|
Functional option: DoNotUseSeparationByDataAreas |
First-time integration:
|
|
Common commands: AddServiceUsers, and CreateBackup |
Add to the configuration command interface. |
Common modules
It is recommended that you follow the approach described in Configuring and updating overridable common modules of the library.
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
See the additional instructions in the Core section. |
|
"Report options" subsystem |
||
|
|
See the additional instructions in the Report options section. |
|
"Batch object modification" subsystem |
||
|
|
|
|
"Period-end closing dates" subsystem |
||
|
|
|
|
"Additional reports and data processors" subsystem |
||
|
|
See the additional instructions in the Additional reports and data processors section. |
|
"Object filling" subsystem |
||
|
|
|
|
"Object attribute lock" subsystem |
||
|
|
|
|
"User reminders" subsystem |
||
|
|
|
|
"Data exchange" subsystem |
||
|
|
See the additional instructions in the Data exchange section. |
|
"Infobase version update" subsystem |
||
|
|
See the additional instructions in the Infobase version update section. |
|
"Send text messages" subsystem |
||
|
|
See the additional instructions in the Configuration update section. |
|
"Print" subsystem |
||
|
|
See the additional instructions in the Printing section. |
|
"Attachable commands" subsystem |
||
|
|
See the additional instructions in the Attachable commands section. |
|
"Duplicate object detection" subsystem |
||
|
|
|
|
"Users" subsystem |
||
|
|
See the additional instructions in the Users section. |
|
"Object prefixes" subsystem |
||
|
|
See the additional instructions in the Object prefixation section. |
|
"Email operations" subsystem |
||
|
|
See the additional instructions in the Email operations section. |
|
"Properties" subsystem |
||
|
|
See the additional instructions in the Properties section. |
|
"Hierarchy" subsystem |
||
|
|
See the additional instructions in the Dependencies section. |
|
"To-do list" subsystem |
||
|
|
See the additional instructions in the To-do list section. |
|
"Access management" subsystem |
||
|
|
See the additional instructions in the Access management section. |
|
"Monitoring center" subsystem |
||
|
|
|
Roles
|
# |
Object name |
Actions required |
|
"Base functionality" subsystem |
||
|
|
When integrating with the "Properties" subsystem but without the "Access management" subsystem, follow the instructions in section Integrating the "Properties" and "Access management" subsystems. |
|
|
Clear the following rights for all metadata objects:
When integrating with the "SaaS" subsystem, add rights to all objects of the DataAreaMainData common separator attribute to the roles. When integrating without the "SaaS" subsystem, add rights to all configuration metadata objects, except for the rights listed above, to the roles. |
|
"Properties" subsystem |
||
|
|
When integrating without the "Access management" subsystem, follow the instructions in section Integrating the "Properties" and "Access management" subsystems. |
Filter criteria
|
# |
Object name |
Actions required |
|
"Hierarchy" subsystem |
||
|
|
First-time integration: set the Contents property and add the types of parent documents, catalogs, and charts of characteristic types to the Type property. Then define which attributes of child document, catalogs, and charts of characteristic types will be used to search for the parent objects. |
Defined types
|
# |
Object name |
Actions required |
|
"Object versioning" subsystem |
||
|
|
First-time integration: configure the type composition as described in the Object versioning section. |
|
"Period-end closing dates" subsystem |
||
|
|
First-time integration:
See the additional instructions in the Period-end closing dates section. |
|
"Additional reports and data processors" subsystem |
||
|
|
First-time integration:
See the detailed instructions in the Additional reports and data processors section. |
|
"Contact information" subsystem |
||
|
|
First-time integration:
See the instructions in the Contact information section. |
|
"User reminders" subsystem |
||
|
|
See the detailed instructions in the User reminders section. |
|
"Item order setup" subsystem |
||
|
|
First-time integration:
|
|
"Users" subsystem |
||
|
|
First-time integration:
|
|
|
First-time integration:
|
|
"Stored files" subsystem |
||
|
|
First-time integration:
See the instructions in the Stored files section. |
|
"Properties" subsystem |
||
|
|
First-time integration:
See the instructions in the Properties section. |
|
"Access management" subsystem |
||
|
|
First-time integration: configure the subsystem as described in the Access management section. During each update, ensure that the type composition includes all supplied types. |
Common forms
|
# |
Object name |
Actions required |
|
"Send text messages" subsystem |
||
|
|
First-time integration: add to the command interface. |
Common commands
|
# |
Object name |
Actions required |
|
"Data exchange" subsystem |
||
|
ConnectionSettings
ImportObjectRegistrationRules
|
First-time integration: configure the subsystem as described in the Data exchange section. |
|
"Hierarchy" subsystem |
||
|
|
First-time integration: set the Command parameter type property for documents, catalogs, and charts of characteristic types to be displayed in the Hierarchy report. |
|
"Access management" subsystem |
||
|
|
First-time integration: configure as described in the Access management section. During each update, ensure that the type composition includes all supplied types. |
Common templates
|
# |
Object name |
Actions required |
|
"Infobase version update" subsystem |
||
|
|
First-time integration: create and maintain a template as described in the Infobase version update section. |
Catalogs
|
# |
Object name |
Actions required |
|
"Currencies" subsystem |
||
|
|
First-time integration: add the Currencies catalog to the command interface. For more information, see the Currencies section. |
|
"Contact information" subsystem |
||
|
|
First-time integration: if necessary, create a set of predefined catalog items. See the instructions in the Contact information section. |
|
"Users" subsystem |
||
|
|
First-time integration:
|
|
"Properties" subsystem |
||
|
|
First-time integration: for each object that will contain additional information, create a predefined item. The predefined item names must have the following format: Type_Name. For example, Catalog_Individuals for the Individuals catalog. See the instructions in the Properties section. |
Data processors
|
# |
Object name |
Actions required |
|
"Application settings" subsystem |
||
|
|
During each update:
|
Charts of characteristic types
|
# |
Object name |
Actions required |
|
"Properties" subsystem |
||
|
|
First-time integration: specify the available types of property values. You can add any metadata object available in the configuration to the list of data types. See the instructions in the Properties section. |
Configuring and updating overridable common modules of the library
It is recommended that you follow the general approach to configuring the overridable common modules:
- 1. During the first-time configuration of an overridable common module, read the documentation for its export procedures and functions. If necessary, implement the logic for the procedures and functions.
- 2. During each further update of an overridable common module, copy the new export procedures and functions, delete the obsolete ones, and ensure that comments, the number of parameters, and the parameter names of each procedure or function match their library equivalents. If necessary, implement the logic for the new export procedures and functions, and update the implementation of existing ones if their purpose or parameters were changed in the new version of the library.
Deleting references to unused subsystems
Some library objects are configured to interact with other library subsystems. In such objects, keep only the code fragments related to subsystems that you integrate. A code fragment related to a subsystem is marked with opening and closing comments:
// <PathToSubsystem> … // End <PathToSubsystem>
For example, if you do not integrate the Properties subsystem into your configuration, delete all the code fragments marked with the following comments:
// StandardSubsystems.Properties … // End StandardSubsystems.Properties
Likewise, if you do not integrate the "Message exchange" subsystem, delete all the code fragments marked with the following comments:
// StandardSubsystems.SaaS.MessageExchange … // End StandardSubsystems.SaaS.MessageExchange
For batch deletion of such code fragments, use the FirstSSLDeployment.epf data processor. Before running it for the first time, you might need to:
- Comment out the code of the managed application module, the ordinary application module, and the session module (to be able to run the data processor).
- Allow editing library objects in the support settings.
Incrementing configuration version number
After you integrate or update the library, increment the version number of the configuration. It is required for proper execution of all infobase update procedures in the new library version. See the additional instructions in the Auxiliary data update upon development section.
Validating integration and updates
It is recommended that you perform the following validation procedures:
- 1. Check the configuration with Perform extended check check box selected (Designer – Configuration – Check configuration).
- 2. Run the configuration in version update mode and in initial filling mode (using an "empty" infobase).
- 3. Use the external report SSLImplementationCheck.erf.
These procedures allow you to quickly identify any incompatibility problems related to library objects that were renamed or deleted from the new library version, and to locate human errors that might have occurred during integration or update. The integration wizard also finds inconsistencies between the planned and the actual scope of library integration into the configuration.
Integrating library subsystems into configuration objects and developing roles
Some subsystems are designed to be integrated directly in consumer configuration objects. See the instructions in the relevant sections of Chapter 3. Setting and using subsystems upon configuration development.
This chapter also provides recommendations for configuring user access rights. Most subsystems include a set of roles for their objects. However, sometimes a configuration developer has to develop a role system and configure roles for objects supplied in the library.
Developing master data for library objects
Most library objects do not include master data because its content depends on the consumer configuration specifics. Master data for library objects must be developed directly in the configuration.
2.3. Using subsystems in configurations
To use most library subsystems, follow the instructions for integration and configuring, add subsystem objects to the command interface, and integrate the subsystem into configuration objects.
Also the subsystems include an API that you can use in your configuration. For the API description, see the library source code. For the description of additional subsystem features for developers, see "Usage upon configuration development" sections in Chapter 3.
The library source code is distributed under the Attribution 4.0 International (CC BY 4.0) license. The license text is available at https://creativecommons.org/licenses/by/4.0/legalcode. This license allows you to use, distribute, rework, edit, and develop the library for any purposes including commercial ones provided that the authorship of the library is indicated in your software.
2.4. Quick start of development "from scratch"
This section contains a quick start guide for SSL-based configuration development. It describes the steps required to run an SSL-based configuration for the first time.
Preparation
- 1. Determine the list of subsystems to be integrated. In the simplest scenario, all SSL subsystems are integrated. It is recommended that you use the FirstSSLDeployment data processor. It allows you to select subsystems for integration and ensures their reference integrity.
- 2. After determining the list of subsystems, click Save settings for Designer and specify the settings file name.
- 3. Create an empty infobase.
Comparison and merging
- 1. Click Configuration – Compare and merge with configuration from file.
- 2. Select the 1Cv8.cf file from the SSL distribution package.
- 3. When prompted to load the full configuration, click No.
- 4. When prompted to enroll for support, click Yes.
- 5. Click Actions – Load settings from file. Select the settings file saved in step 2 of the Preparation stage.
- 6. Then click Execute.
- 7. If a window informing about unsolved references is displayed, skip the messages in this window and click Continue. This window is displayed when you do not integrate all SSL subsystems. See an example in Integrating the "Data exchange" subsystem without the "Email operations" subsystem.
- 8. In the Specify support rules window, click OK.
Actions after comparison and merging
- 1. Type the configuration name in the configuration properties. Example: MyConfiguration.
- 2. In the configuration properties, set the version number. For example, you can set the version number to 1.0.1.1 when you start developing a configuration.
- 3. Copy the InfobaseUpdateSSL common module.
- 4. Replace the name of the copied module with the name or abbreviation of the configuration name (for example, InfobaseUpdateMC).
- 5. Replace the module text with:
Procedure OnAddSubsystem(Details) Export
Details.Name = "MyConfiguration";
Details.Version = "1.0.1.1";
// Standard Subsystems Library is required.
Details.RequiredSubsystems.Add("StandardSubsystems");
EndProcedure
Procedure OnAddUpdateHandlers(Handlers) Export
EndProcedure
Procedure BeforeUpdateInfobase() Export
EndProcedure
Procedure AfterUpdateInfobase(Val PreviousVersion, Val CurrentVersion,
Val CompletedHandlers, OutputUpdatesDetails, ExclusiveMode) Export
EndProcedure
Procedure OnPrepareUpdateDetailsTemplate(Val Template) Export
EndProcedure
Procedure OnAddApplicationMigrationHandlers(Handlers) Export
EndProcedure
Procedure OnDefineDataUpdateMode(DataUpdateMode, StandardProcessing) Export
EndProcedure
Procedure OnCompleteApplicationMigration(Val PreviousConfigurationName, Val PreviousConfigurationVersion, Parameters) Export
EndProcedure
In the OnAddSubsystem procedure, replace the configuration name and version number with the name and number specified in steps 1 and 2.
- 1. Allow editing the ConfigurationSubsystemsOverridable module and add the following line to the SubsystemsOnAdd procedure:
SubsystemsModules.Add("InfobaseUpdateMC");
- 2. In this line, specify the name of the module created at step 4.
- 3. Run the configuration for the first time. Ensure there are no errors during the initial filling.