The following section covers all topics related to the active configurable elements within ConfigPortal, regardless of the selected Product Config Module.
Additionally, users should take into account special considerations and principles behind ConfigPortal’s configuration approach under Special Considerations. Any additional special consideration particular to a product is available under its respective Functional Use Case sections.
Please note that the content covered in this section assumes that the user possesses the necessary administrator rights as well as having selected an Active Staging Environment as shown in the image below.
The following concepts are critical and must be covered and considered before readers attempt to actively use ConfigPortal in the context of configuring and editing use cases.
The following example is used to illustrate the relationship between terms and the object they refer to.
Product Config Module: The navigation option grouping configuration options that are relevant to a particular product. This may also house the same global configuration options as other products due to these being shared across the system.
Functional Use Case Category: A category used to group a variety of functional use cases.
Functional Use Case: A configuration set, that may very depending on the concrete cases. Example: “Ingest” as a Watchfolder is a functional use case that can be attributed to the ingest topics.
Concrete Use Case: A specific configuration of the Functional Use Case. Example: “Watchfolder for Editing”.
Active Staging Environments
There may be multiple Staging Environments, but only Active Staging Environments are editable. Specifying which Staging Environment is active can only be done by an Arvato Systems engineer.
The Active Staging Environment is also defined as being the instance of ConfigPortal where products are connected. The nature of the Staging Environment as Active or Inactive cannot be changed during system runtime. If changes of this nature are required, users must contact Arvato Systems to clarify the impact of the installation.
Staging Environment Dependent Values
A “Flag” icon indicates that the value for that parameter can vary from Staging Environment to Staging Environment. The same Concrete Use Case may have different values for those parameters in the INT Staging Environment than it does in the TRANS Staging Environment. Staging Environment dependent parameters and values are those that describe network infrastructure elements. These include host names, IP addresses, web service endpoints or credentials.
Activating a Concrete Use Case
The “Status” toggle is by definition a Staging Environment dependent value. This implies that users are able to select a Concrete Functional Use and choose whether that Concrete Case is active from Staging Environment to Staging Environment. Please note for ConfigPortal users, of the customer nature, toggling the Status as “active” and saving results in that Concrete Use Case will take effect. These configurations are to be triggered based on its defined logic.
Users are able to deactivate (switch-off) a Concrete Use Case for maintenance reasons or during the Staging process (synchronizing of configuration data from one Staging Environment to another).
Global Configuration Pages
These Pages offer the foundation on which workflows, storages or metadata can be defined and made available as global technical objects to be use in Functional Use Cases. Configurations that are added, edited or removed here have an impact on any Concrete Use Case the employs them. Any workflow, storage or metadata choices made for a Concrete Use Case are based on the pool of options available in the Global Configuration Pages. Additionally, the “Usage” action button allows users to view a list of all the Use Case Pages that employ a Global Configuration.
Guids are internal unique identifiers for ConfigPortal. These are primarily used as unique ID across all Staging Environments for the purpose of synchronizing data among Staging Environments. Additionally, these are used to trace Concrete Use Case activity.
Editing a workflow and publishing it into the system (via the Workflow Designer), will automatically create a newer version of the workflow. Users may have to select this manually in the Concrete Use Case’s editing Page, when specifying the workflow.
Alternatively, if the workflow settings for “Version” are set to “Latest”, that Concrete Use Case will always use the latest version of the selected workflow.
Please note that workflows created or edited under Global Configuration Workflows, will affect the availability and selection of underlying workflows. Editing parameter values for Concrete Use Cases, does not affect the workflow design itself, only the parameter values. This is done in order to preserve the integrity of the workflow at a global level.
Concrete Use Cases
When editing Concrete Use Cases under a Functional Use Case, users have the opportunity to specify a series of options. The nature and availability of the parameters vary based on the Functional Use Case. These are covered individually for each Product Config Module’s particular Functional Use Cases and can be viewed in detail under their respective Considerations sections.
There are however a series of recurring options that are common throughout Functional Use Cases:
Names and Labels
Activate and Deactivate
Names and Labels
When editing Concrete Use Case, users may edit both the “Name” and “Label”. While the name field determines the internal reference name, the label acts as the its display name.
Please note that the Guid serves as the unique identifier.
When editing Functional Use Cases, users may be given the opportunity to select from a list of workflows via a drop down menu. These are the workflows which are either currently available upon delivery of the system, or those workflows which can be created and modified via the Workflow Designer – available with VidiFlow.
Please note that by selecting and saving a particular workflow to a Concrete Use Case does not guarantee that it will be executed successfully. Users are expected to be fully aware of the workflow they are selecting when editing a Concrete Use Case.
Storages can be selected from those from the existing Global Configuration Storage Pages. Access types are created and defined individually for each storage. When selecting a storage for a Concrete Use Case Page, are then able to choose from the access types that have been defined.
Activate and Deactivate
When editing Concrete Use Cases, users must activate it for the configuration to take effect. This can be done under “Status” as shown below.