Versions

Most of the changes made in beVault are only metadata. They don’t physically create something. That is why we create and deploy versions of beVault to different environments. It is only with this feature that the tables are created in the databases.

Create a version

To create a new version, click on the “Create Version” button in the top-right corner. A pop-up wizard will appear, asking you to give the new version a name. Once you have provided a name, you can create the version.

Once the version is created, the table will automatically be filled in with additional information listed below

• Name: name given at creation.

• Username: name of the user who created the version.

• Date of Version: date & time of version creation.

• Actions: allows the user either to send workflows (deploy) or delete a version.

Release a version

Users can deploy a new version to an environment to apply the changes they made with the dedicated button

 The following pop-up wizard will require the user to select an existing environment before deploying the version by clicking on the button at the bottom-right.

After clicking on Deploy, a summary wizard will pop up with details of the deployment. On this page, you will find all the changes that will be applied to your environment.

From this page, you can perform the following actions

• “Download deployment scripts”: This action will download a single SQL file with the deployment script of the version. This script can be executed by a database administrator if beVault does not have all required rights to the database.

• “Execute deployment”: This action will execute the SQL script to deploy the version on the environment.

• “Next Step”: once deployed, either manually by downloading the script or automatically with the execute button, you can proceed to the next step to deploy the state machine in the orchestrator.

Download deployment scripts

When deploying a version to an environment, you have the possibility to download the DDL queries to apply the version to the database.
The DML queries used by States are also available in the archive so that you can use any orchestration tool you like.

Archive structure

📁 [version]

• 📄 DeployModel.sql _{- DDL script for deploying/updating data model version from beVault}

• 📁 LoadQueries _{- Folder containing all loading processes (state machines)}

  • 📁 generate-[IM name] _{- Information Mart generation state machine}

    • 📄 [x]_im_[IM name]_im_[order]_[script name].sql.liquid _{- Contains Liquid template scripts that generate Information Mart}

  • 📁 Load_Snapshot_[snapshot name] (CFR Data Workflows | Data Quality workflow)

    • 📄 [x]_insert_snapshots_im_ctrl_[snapshot name].sql _{- insert new snapshot date in the snapshot group table}

    • 📄 [x]_delete_old-snapshots-from-pit-table_bv_[ pit table name].sql _{- remove records related to old snapshot dates in pit tables}

    • 📄 [x]_delete_old-snapshots_ctrl_[snapshot name].sql _{- remove old snapshot dates from the snapshot group table}

    • 📄 [x]_load_bv_[ pit table name].sql _{- load data related to new snapshot dates in pit tables}

    • For each entity on which there is a DQ check related to the snapshot

    • 📄 [x]_truncate_stg_[snapshot name]_[entity name].sql _{- truncate the staging table containing the recomputed DQ checks}

    • 📄 [x]_load_stg_[snapshot name]_[entity name].sql _{- recompute DQ checks}

    • 📄 [x]_truncate_stg_[snapshot name]_[entity name]_l2.sql _{- truncate the staging table lvl2 containing the recomputed DQ checks}

    • 📄 [x]_load_stg_[snapshot name]_[entity name]_l2.sql _{- recompute the hashes of DQ checks and load the result in the staging lvl2}

    • 📄 [x]_load_stg_[snapshot name]_[entity name]_hub[_x].sql _{- load the BK found in the DQ in the hub. In case of a DQ check on a link, the script is suffixed with an auto-incremented number}

    • 📄 [x]_load_stg_[snapshot name]_[entity name]_link.sql _{- load the link of the DQ check}

    • 📄 [x]_load_stg_[snapshot name]_[entity name]_sat.sql _{- load the satellite of the DQ check containing the result}

  • 📁 Load_Snapshot_[snapshot name] (CFR https://dfakto.atlassian.net/wiki/x/JoBVUQE)

    • 📄 [x]_truncate_ref_[ref table name].sql _{- In case a referential table is mapped, this table is first truncated}

    • 📄 [x]_load_stg_[ref table name]_[mapping code].sql _{- In case of a referential table being mapped, the table is loaded directly from the stg lvl1 table}

    • 📄 [x]_truncate_stg_[staging table name]_l2.sql _{- truncate the stg lvl2 table}

    • 📄 [x]_load_stg_[staging table name]_l2.sql _{- compute the hashes and load the data from the staging lvl1 into the stg lvl2}

    • 📄 [x]_load_stg_[staging table name]_l2_[mapping code].sql _{- load the data from the staging lvl2 into the different entities based on the mapping (some scripts can be run in parallel even though the [NNNN] is an auto-incremented number)}

    • 📄 [x]_load_stg_[staging table name]_l2_[mapping code]_ef.sql _{- In case of full load, load the effectivity satellite}

Delete a version

Finally, a user can delete a version by clicking on the “Delete” button in the column “Actions”.

The following pop-up wizard will require the user to confirm the deletion before deleting it permanently.