You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 42 Next »
The SimpleOne system allows exporting and importing configuration packs to keep unrelated instances synchronized.
Concept
In brief, the VCS configuration pack conception can be defined as an ability to transfer data from one instance to another in an automatic or semi-automatic way. It is intended for application version control. Configuration packs help to automate transfer data and configurations from one instance to another, lessen the manual effort. The key point is configurations transfer. For not to reiterate it more and more on every instance, you can just import a configuration pack. So, this technology really is to make it easy and automate a migration update from one instance to another.
Application configurations are stored in configuration packs, which are represented as a .SOP file containing a set of the application version records. In an OOB supply, the SimpleOne platform contains only the Simple application, but administrators (users with the admin role) can create their own Applications if needed.
There can be more than one local pack in the system, but the changes made by a single source can be written only in one localpack at every moment. You can choose the preferable localpack using the Preferences menu at the right. See the Admin Preferences article for the details.
Initially, the configuration pack should be assembled on the source instance (the instance containing source data) within the local pack related to the specific application. After that, the local pack can be exported to the configuration pack as a .SOP file.
Please note: all system configuration activities should be performed within a detached local pack (do not use default local pack for these needs).
Using configuration packs allows deploying this configuration on other instances or, if needed, rollback versions of the specified record or some local pack as a whole to the previous state.
Technically, the configuration pack is the set of the saved records from the VCS Record (sys_vcs_record) table. Every record of this table contains JSON formatted changes and other attributes described below.
{"value": "Report Item", "policy": "Open", "sys_id": 159653803414986194, "column_id": 156941403909472422, "record_id": 159653803414985080, "language_id": 156628684306541141, "application_id": 155931135900000002, "sys_created_at": "2020-08-04 10:47:14", "sys_created_by": 155931135900000001, "sys_updated_at": "2020-08-04 10:47:14", "sys_updated_by": 155931135900000001}
The configuration pack transfer between instances can be also called "import". On the picture below, you can find the cross-instance configuration versions import flow:
Flow Legend
In the picture above, blocks colorization is based on the tables affected as described below:
Table | Color |
---|---|
VCS Record | Blue |
VCS Local Pack | Green |
VCS Preview Log | Yellow |
VCS Retrieved Pack | Orange |
Retrieved Records | Red |
No tables affected | Grey |
Record versions
After any transaction (create/update/delete) for the versioned table object, the record is created in the VCS Record (sys_vcs_record) table corresponding to the object state after the transaction. The record version contains the information described below.
VCS Record form fields
Field | Description |
---|---|
Record | An ID of the source record processed by the transaction. |
Table Name | The table name for the target record. Please note that only system names for tables are used in this field, not titles. Right: sys_vcs_record. Wrong: VCS record. |
Record Document | This ID stores table name and target record ID for which the current record is created. For example: |
Is Current | This attribute is responsible for current version relevance. When its value is equal to "true", the version corresponds to the target record state relevant for now. |
JSON Copy | The record version data in JSON format as an associative array. This array stores the target record object relevant state after the transaction. |
Action | Transaction type. Available options:
|
Local pack | Reference to the local pack containing this record version. |
Retrieved pack | Reference to the configuration pack containing this record version. |
Record Policy | The current record protection policy after the transaction is over. |
Protection Policy
The Protection Policy (policy) attribute is responsible for the possibility of the record changing (for example, overwriting). It it used, in particular, for data protection purposes.
How it works
When the record in the versioned table is created, its Record and Record Policy attribute values are equal to Open. After first update, its Record and Record Policy attribute values changes to Changed.
Records with these two states for the Record and Record Policy attributes are freely modifiable.
Another protection policy state for record is Protected. Records with this state cannot be changed or deleted.
During the importing process, the records possible to overwrite can be updated. Both record policy values set in the system and in configuration pack are taken into account. All possible policy combinations are described in the table below.
Local Pack importing policy value | Local record policy value | Local Pack importing attempt result |
---|---|---|
Protected | Protected | Success |
Open | Success | |
Changed | Success | |
Changed | Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success | |
Changed | Success | |
Open | Protected | Failed. Use Strong Overwrite to proceed. |
Open | Success | |
Changed | Failed. Use Strong Overwrite to proceed. |
Local packs
Technically, a local pack is a record in the VCS Local Pack (sys_vcs_local_pack) table related to versions of the related records in a VCS Record (sys_vcs_record) table. Every single version is an atomic state of versioned tables (those ones which have the is_VCS_enabled attribute turned ON). All record versions in the local pack are displayed on a related list on a local pack form.
To create a local pack, please complete the steps below:
- Navigate to Configuration → Local Packs.
- Click New and fill in the fields.
- Attach the file you need by clicking the attachments button
.
- Click Save or Save and Exit to apply changes.
VCS Local Pack form fields
Field | Mandatory | Description |
---|---|---|
Origin ID | N | This ID is assigned to the local pack after creating it on a source instance. |
ID | N | This ID is assigned to the local pack after importing. |
Is Default | N | This attribute defines that this local pack will be set as default for any user changing the application to the one specified in the Application field. |
Application | N | Specify an application of which record changes are stored in this local pack. |
State | Y | Local pack state. Available options:
|
Description | N | Local pack description. |
Completed at | N | The date and time when the local pack state changed to Completed. |
Completed by | N | Reference to the user who has set the state to Completed. |
Version restoring
A non-actual version (the is_current attribute value is equal to FALSE) can be restored if needed. To perform this, please complete the steps below:
- Navigate to Configuration → VCS Records.
- Find the record to be recovered. You can use list search for search criteria narrowing, or a Condition Builder.
- Click on a desirable record to open it.
- Click Restore Version.
After that, a new VCS record is created in the current local pack. The Restored by field value of this record is equal to the ID of the version used for restoring.
You can add a versions list to the versioned table form as a related list. After that, all previous versions of the current record are displayed on the record form.
Default local pack
Default local pack is a local pack named "Default 1" created automatically after creating a new application.
It is not recommended to use the Default 1 local pack to store versions for the purpose of further import to other instances. Create separate packs for these tasks.
If a version has been created in a default local pack erroneously, then you can move it to the required local pack. For this, please complete the steps below:
- Navigate to Configuration → Records.
- Find the record to recover. You can use list search for search criteria narrowing, or a Condition Builder.
- Click on a desirable record to navigate into it.
- Click the magnifier icon on the left of the Local Pack field and choose the required local pack.
- Click Save or Save and Exit to apply changes.
Local Pack Exporting
After you are done with record versions collection within the task implementing, you need to export the changes for further import to other instances. For this, please complete the steps below:
- Navigate to Configuration → Local Packs.
- Find the local pack to export. You can use list search for search criteria narrowing, or a Condition Builder.
- Click on a desirable local pack to navigate into it.
- Change the state value to Completed.
- Open the hamburger menu and navigate to Export → As a New Application.
Recommendations:
- It is a good practice to give a relevant name to the local pack after exporting, for example:
- Good – "New Incident States.sop"
- Bad – "some task.sop", or leaving the name generated by system, like this: 2020-08-06_08-47-19_159654161718816631.sop
- Also, it is recommended to download your local pack straight away after the job is done; otherwise, the versions stored in it may go out of date.
Local Pack Merging
Two local packs can be merged in one if necessary. For this, please complete the steps below:
- Navigate to Configuration → Local Packs.
- Choose local packs you need to merge by selecting the appropriate checkboxes, then click the Merge button.
- Fill in the name and description of the consequent local pack.
- Wait until local packs are merged.
- As a result, a new local pack is created, referenced with the last versions of the VCS Record (sys_vcs_record) for every record.
- Resulting local pack transits into the In Progress state.
- The original local packs are removed.
- If any versions were referenced to original local packs and didn't get into the resulting one, then this reference is reset.
Team Development
In SimpleOne, you can perform your parallel development on multiple instances. For now, team development is represented an an operation approach and is handled by two engines:
- Configuration packs
- Merging.
In brief, in order to facilitate the team development process, you need to perform the steps below:
- Every team member does his work part. It is written down on the instance in the configuration pack.
- When the development is over, these configuration packs must be exported onto the main one and merged.
- After merging, work on collisions if there are some, and after that, the final configuration pack will be the result of the team development.
Local Pack Import
To deliver an exported local pack on a target instance, the import procedure should be continued. What is implemented within this procedure:
- The transactions stored in configuration pack (a local pack that was exported) are applied to the target instance.
- A local pack copy created on a target instance.
To import a local pack, please complete the steps below:
- Navigate to Configuration → Retrieved Packs.
- Click New to create a new configuration pack.
- Attach previously exported .SOP file to this configuration pack.
- Click Save or Save and Exit to apply changes.
- Click Load pack button on the top right to load records from the attached .SOP file to temporary table.
Please be noted that if you are attaching more than one .SOP file to a retrieved pack record, then records will be collected only from the last one.
After records are loaded, additional UI actions appear on the retrieved pack record form:
- Reload pack
- Prepare changes
- Import pack
VCS retrieved pack form fields
Field | Mandatory | Description |
---|---|---|
Name | N | Retrieved Pack name, taken from the SOP file attached. |
State | Y | State of the current configuration pack imported. Available options:
|
Remote ID | N | ID of the local pack exported. |
Remote Application | N | Application specified in the local pack exporting. |
Application | N | Specify the application within which the pack should be imported. |
Inserted | N | The number of records in this pack with the Action attribute value equal to Insert. |
Updated | N | The number of records in this pack with the Action attribute value equal to Update. |
Deleted | N | The number of records in this pack with the Action attribute value equal to Delete. |
Warning | N | The number of the Preview Log records with the State equal to Warning. |
Skipped | N | The number of the Preview Log records with the State equal to Skipped. |
Collisions | N | The number of the Preview Log records with the State equal to Collisions. |
Total | N | Total records number. |
Description | N | Retrieved Pack description, taken from the SOP file attached. |
Loaded at | N | The date and time when the configuration pack import has been finished (the state has been changed to Loaded). |
Committed at | N | The date and time when the configuration pack was applied (the state has been changed to Committed). |
The import process includes two immanent phases described below:
- Previewing pack and preparing changes
- Importing.
Preparing and importing
During this phase, the import engine checks for the possible conflicts before the pack is imported. To preview the configuration pack, please complete the steps below:
- Navigate to Configuration → Retrieved Packs.
- Find the configuration pack containing previously loaded records to preview (you can filter the list by the Previewed state).
- Click on the selected pack to navigate into it.
- Click the Retrieved Records tab.
On this tab, you can find all records loaded from the configurations file. The Retrieved Records functionality allows to filter records out by state, fix errors if necessary and go on with importing without reassembling the .SOP file.
Retrieved record form field
Field | Description |
---|---|
Table Name | The target table name in which this record version should be created. Please note that only system names for tables are used in this field, not titles. Right: sys_vcs_record. Wrong: VCS record. |
Record ID | This field stores target record ID for which the current record is created. |
Document Record | This field contains VCS record unique ID of the Document ID type. It is generated out of the table ID the record related to and the record ID. |
Created by | Reference to the user who has created the initial record. |
JSON Copy | Record version in JSON format. |
Is Strong Overwrite | If this attribute value is equal to TRUE, then this version will take precedence over the existing version when the import process will go on. |
Action | Transaction type. Available options:
|
Retrieved Pack | Reference to the retrieved pack containing record version. |
Record Policy | The current record protection policy after the transaction is over. See the relevant article section for more information. Available options:
|
Use case
After loading a .SOP file into a retrieved pack record, some VCS records have thrown errors due to some reasons (for example, the translation records on the target instance are different from the ones in retrieved pack, what causes data inconsistency, or any other reason). In this case, a person implementing import should follow the steps as described below:
- After navigating onto the configuration pack being imported, click on the VCS Preview Log tab.
- Find the erroneous records (filter out the Good state).
- Click on such a record.
- Read the text in the Error Text field to get the error cause.
- Make necessary changes to the record in the JSON Copy field and save the record by clicking the Save or Save and Exit button to apply changes.
- Click the Prepare changes button.
- Make sure that record state has been changed to Good.
- (optional) Repeat these steps for every erroneous record if there are more than one.
- After you are done, click the Import Pack button on the retrieved pack form.
After a pack is finally imported:
- A local pack record in the target instance is created.
- All versions created on the previous stage are copied onto this local pack.
- The is_current attribute value for these records changes to TRUE.
- All records from this pack are created in the target instance in relevant tables.
- Temporary records from the Retrieved Records table are deleted.
- The retrieved pack state changes to Committed.
- The date and time of this operation are displayed at the Committed at field.
- Keep in mind that if any collisions occurred during the local pack preview, the process will be canceled on the first occasion, the others will not be shown.
- Please be noted that if you are attaching more than one .SOP file to a retrieved pack record, then records will be collected only from the last one.
- If you need to load records from another .SOP file without creating new retrieved pack record, then complete the steps below:
- Click on the attachments icon
on the top right.
- In the attachment widget form, attach another .SOP file to import.
- Click the Reload pack button.
- Click on the attachments icon
VCS Preview Log fields description
Field | Description |
---|---|
Local Pack | Reference to the local pack containing this preview log record. |
Retrieved Pack | Reference to the configuration pack containing this preview log record. |
Record Document | ID of the target record for which the transaction has been executed. |
Table Name | The table name for the target record. Please note that only system names for tables are used in this field, not titles. |
Record | This ID stores table name and target record ID for which the current record is created. |
Platform Version | The solution platform version used when the record created. |
JSON Copy | The record version data in JSON format as an associative array. This array stores the target record object relevant state after the transaction. |
Error Text | The error text displayed in case of collision (the preview log record state is equal to Warning or Skipped or Collision). |
State | The preview log record state. Available options:
|
Action | The type of transaction created the version object. Available options:
If the record with action = Update is absent on target instance, then it is imported with the action = Insert (the new record is created instead of updating the existing one). |
Record Policy | The attribute responsible for the record protection policy. See the relevant article section for more information. Available options:
|
Is Strong Overwrite | This attribute determines the priority of the imported version over the existing one. |
VCS Record | The related version record created after configuration pack importing. |
Application | The application within of which the preview has been executed. |
States Information
- Good – this state indicates that this configuration pack version will not cause import conflicts.
- Skipped – this state indicates that this version importing was skipped within the whole import process.
- Warning – this state indicates that the version cannot be applied in part or in a whole.
- Collision – this state is critical to the import process. The version with this state cannot be imported.
- Allowed – this state is similar to the Good state. It is set to version after rollback operations.
Please keep in mind that if any collisions occurred during the local pack preview, the process will be canceled on the first occasion, the others will not be shown.
Collisions processing
Generally, collisions may appear during the configuration pack import process. Their leading cause is that the dependent table or record does not exist in the database.
Consider a common use case:
- We have exported the Incident table, child for the Task table.
- We import it to the instance without the Task table.
- In this case, the Incident table cannot be created on the target instance, because there is no parent table from which to inherit.
After that, you can find the erroneous record at the VCS preview log related list (in the VCS Retrieved Pack section). This record has the state = collision and the appropriate Error Text containing the error cause. Erroneous records cannot be included in the saved records pack (VCS Records) bound to the retrieved pack that is used for data recovery.
Collisions disposal methods
The idea in the collision fixing process is to try to dispose of collisions in the highest level tables. This method allows removing collisions in the lower-level tables automatically. It can be done about like this:
- Filter the records in the VCS Preview Log by the state (state = collision).
- Analyze errors for the records at the top of the list.
- Alternative way: you can filter the list by the Table field. The highest-level tables to analyze are, for example, sys_db_table, sys_number, sys_db_column, and some others.
- After the error cause was found, it must be fixed on the source instance. The configuration pack is to be exported and previewed again by clicking Preview Again Local Pack.
- If collisions are gone, then this configuration pack can now be imported. Herewith, all the records from the last configuration pack attached are imported. The retrieved pack status changes to Loaded. The records are added to the VCS Record (sys_vcs_record) table. The last preview log is available in the Related Lists area.
- After importing, the retrieved pack applying possibility appears. For this, click Apply Local Pack. The system restores records from this configuration pack (in other words, from the VCS Record (sys_vcs_record) table records attached to this retrieved pack). The retrieved pack changes its state to Committed.
- If the collisions are not gone, then return to the previous steps.
Collision case 1
When installing a configuration pack in the system, some record “X” is added. At the same time, it is referenced to another records “Y” in this system and in this configuration pack. Both records that the record ‘X’ is referenced to do not exist. When the export admin initiates a configuration pack preview (using a Preview Local Pack button), the collision is thrown on this record, which is an expected result.
Collision solving:
The solution is the configuration pack rebuilt in order to get the record “Y” into it.
Collision case 2
The record “X” is deleted from the system. At the same time, there is a reference to this record in the configuration pack. When the export admin initiates a configuration pack preview (using a Preview Local Pack button), the collision is thrown on this record, which is an expected result.
Collision solving:
The solution is the configuration pack rebuilt in order to remove this record from it.
Collision case 3
Create a table in the source instance, with the field number equal to N.
Create the same table with the same name in the target instance, with the field number equal to N-1.
In the source instance, perform the export of the table fields into a configuration pack, after that download a .SOP file and unpack it in the target instance.
The result will be a collision thrown, and a message that this object is not valid, any actions on it cannot be taken.
Collision solving:
To solve this collision, create or update the object, excluding attributes missing on the target instance. In the above example, the N-fielded table will be successfully imported to the target instance, where the (N-1)-fielded table is created. But, the fields that exist in the source instance and are not in the target instance will not be created in the target instance. See the schema below.
Collision case 4
The records on a target instance are newer than in a configuration pack to install. It can be determined by the date and time of record creation.
Collision solving:
Export admin needs to initiate a local pack preview. In the process:
- Collision-causing records will be marked with the Skipped state.
- When applying the local pack, the records with this state will be skipped. The records that were present on the target instance initially will stay.
- In the case of record in the configuration pack is newer than on the instance, then it will be marked with the Good state, and it will replace the record on the instance.
Collision case 5
A table being deleted from instance contains records (is not empty). If the table being deleted is empty, then there is no collision.
Collision solving:
- Collision-causing records will be marked with the Skipped state.
- When applying the local pack, the records with this state will be skipped.
- If the record was marked with the Good state, then the table will be deleted.
Collision case 6
A configuration pack contains objects related to the application X. At some moment, export admin tries to apply this configuration pack to the instance that does not have this application installed.
Collision solving:
The solution is to rebuild the configuration pack in order to add records related to the missing application.
Collision case 7
Partial attributes mismatch between instances.
Use case description.
Create a table on the source instance, with the field number equal to N.
Create the same table with the same name on the target instance, with the field number equal to N-1.
On the source instance, perform the export of the table fields into a configuration pack, after that, download a .SOP file and unpack it on the target instance.
The field names on source and target instances are slightly different. See the schema below.
Collision case 8
The collision cause is unique key violation.
Use case description
- It was discovered that the target instance (instance #2) contains incorrect translation record for some element (element #1) or does not contain any translation record. This record should be located in the Translations (sys_translation) table.
- This translation record for the element #1 has been created in an appropriate table on the instance #2.
- On instance #1 (the source instance), a .SOP file has been assembled containing translation for the element similar to element #1. The column_id, record_id and language_id fields necessary for UNIQUE CONSTRAINT forming matched up on both instances.
- This .SOP file has been uploaded on instance #2 like described above. VCS preview logs were generated.
- After loading a pack on instance #2, a collision VCS record appeared containing an Error Text more or less like this:
- "This record has a duplication of a unique key. DETAIL: Key (column_id, record_id, language_id)=(156941403909472422, 159170696512371798, 156628684306200767)."
Collision solving
The collision solving method is to decide which translation record is more up-to-date.
If an initial record located on the target instance is more up-to-date, then the collision record can be dropped from the configuration pack and not imported.
If a new record being imported is more up-to-date, then this record should be imported, what will cause initial record overwrite.
Snapshots
In version control systems (VCS), snapshot is the fixed system or database status description. To create a table snapshot, the table managing form can be used, and also, server-side API class SimpleVcs was implemented.
Role required: admin.
Option 1
- Navigate to System Definition → All Tables.
- Using the search bar and/or a Condition Builder, find the table for which you want to create a snapshot, and navigate to it.
- Open the hamburger menu and navigate to Configure → Table.
- Click the Create VCS snapshot button at the right top. This button is visible only when the versioning for this table is on (the is_vcs_enabled attribute is set to TRUE).
Option 2
- Navigate to System Definition → Scripts.
- Write down a script and call createTableSnapshot(tableName) method in it.
In both cases, the result is the snapshot, that is, the set of the VCS records for all the documents in this table that do not have such records at the moment of the snapshot creating.
Rollback
Rollbacks in brief
- Any completed local pack can be rolled back.
- Rollback will restore the versions of all the records in this local pack as they were before the start of the update collection within this local pack, or before committing this local pack.
- Deleted records are restored, and created records are deleted.
Example
- Before local pack committing, the record had a version X.
- After the local pack committing, it has version Y.
- And after rollbacking, it will have version X again, even if after local pack completing it had any other version.
How to rollback a local pack
To rollback a local pack, please complete the steps below:
- Navigate to Configuration → Local Pack.
- Click on the local pack you need to rollback and navigate into it.
- Click Rollback Preview to preview the list of the records that are going to be backed out.
- Review the contents of the local pack, fix the possible collisions if required. After fixing the collision, please complete the steps below:
- Navigate to Configuration → VCS Preview Log.
- Click on the record that was causing the collision.
- Click on the State choice list and select the allowed value.
- Click Save or Save and Exit to apply changes.
- Click Rollback to perform the rollback.
Resolve the issues encountered.
The currently selected application affects what options are available for the local pack. So please make sure that you select the application, such as Platform, that matches the content of the local pack.
Do not rollback the Default 1 local pack without an absolute necessity; otherwise, your SimpleOne instance configuration may be damaged.
Rollback of any local pack is an operation that shouldn't be invoked without an emergency need; so use it cautiously.
This process both record updates and dictionary changes. Some changes caused by the rollback may lead to data loss.
Here is the expected result of the process:
Update | Rollback result |
---|---|
A new table | The table is dropped from the database, deleting any data from it. |
A new field | The field is dropped from the database, deleting any data from it. |
A deleted field | The field is restored to the database, but the original data is lost. |
A record is inserted | The record is deleted. |
A record is deleted | The record is restored with its original data. |
- No labels