Realization Overview in ConfigPortal

The image above depicts a high level overview of Staging's underlying design concept. The diagrams depict two Stages, the TRANS and PROD Staging Environments.
Each side illustrates two Staging Environments located in different networks completely separated from each other. In order for this to be true, the instances of the used software must be installed per network and per Stage separately.
ConfigPortal itself comes with an own data store which persists in all Stages. The benefits implied with this are varied as users are able to easily see and compare configurations per Staging Environment in the ConfigPortal UI as well as synchronize Stages using this data. Per installation, a Staging Environment can be assigned as active. The active Staging Environment data can then be edited by ConfigPortal users to later be synchronized and merged.
The purpose of this is to have the same functional configuration across all Stages in ConfigPortal. ConfigPortal saves the data for all Stages whenever configurations are added or modified. Configurations changes are saved for each Environment in which they are made, but only via synchronization are they applied to the target Staging Environment.
Software consumers, such as VidiFlow, MediaPortal, EditMate or any other consumers do not need to be aware of the Stage they are running in. The ConfigPortal API will deliver the data of the active Stage to the products when requesting data.
Another aspect which must be considered is the different networks which are used for installation. This is due to the fact that a test system may and should not be connected directly to the production system. In order to synchronize the data from one Stage to another the user must transport data. This is achieved by downloading the data from one Stage and uploading into the intended Stage. Users are guided through the process by following the steps described in the [Step-by-Step: Staging section Step-by-Step:_Staging .

ConfigPortal with VidiFlow

Another important aspect to take into consideration is the fact that a synchronization with the Vidispine API will be made in which Vidispine relevant data objects (storage or metadata fields) are managed.
As the synchronization process is such a crucial process, it is necessary to perform it after every configuration change. In order for debugging and analyzing problems to be done effectively in the system, this process needs to be executed in all Stages after reconfiguring the systems.