QW QEF - Administration - Best Practices

This document describes the best practices for QualiWare System Administration

Repository and Data Management Best Practices 

Moving QualiWare QIS Repositories  

There are a variety of reasons for moving a QualiWare repository or moving a subset of the data in a repository to another repository in a QIS (QualiWare Integration Server) environment including:

• Moving data to a different database server (i.e., infrastructure change on the same network)
• Moving data to a different database server (i.e., changing data classification requires a transition to a more secure or different network environment)  
• Consolidating repositories  
• Transitioning from on-premise to cloud infrastructure  
• Transitioning from database as a service implementation (i.e., Azure Elastic Pool) to a dedicated database server  
• Fixing an incorrectly created repository (rare case)  

  

This chapter describes some best practices and other considerations when planning to move QualiWare data/repositories. 

When shouldn’t you move Repositories?  

Moving repositories is not required when, upgrading, or moving QIS/QEF installation to a different server. It's important to note that when you are moving to a different server you will need to replicate the QIS Repository values from the existing server to the replacement server (e.g.  connections strings, metamodel, etc.) 

 Repository Move 

There are two methods for moving QualiWare repositories. These methods move everything including all revisions, models, objects, QCL Setup, Add-ons, and configurations.  

1. Database back-up and restore – System administrators can move a repository using the database backup and restore options. Once the recovery database has been created, you must set up a New Repository in the QIS Repository Administrator, configure the repository as the previous configuration, and apply the correct connection information to point the repository database to the recovered database. 

a. There are a couple of extra things that will need to happen in this type of recovery. Groups and Users will need to be reconfigured, and manual updates of the log file, governance, social behavior, etc. Connection strings will need to be reconfigured before they work properly.

b. The order of completing the database string should be done in this order. 

1. QEF/QIS database 
2. QEF Data sources 
3. Access Log 
4. Repository Definition 
5. Repository Administration 

2.   Dump, Load, and Dump loader - To create a dump of the entire repository (it contains all  sources content, versioning history, etc.) 
a.  Open QLM -> File -> Import and Export -> Copy Repository to Dump 
 
b.  Once the Repository Dump is complete go to the model’s directory on the QualiWare Server and locate the QLMDumpLoad.exe (Using the “Load Repository from Dump file” will generate a message to use the QLMDumpload.exe)  
 

You should note that it can take a very long time for “QLMDumpload.exe” to complete. Once it does, it will notify you that the process is complete. 

Things to do before loading a dump file. 

1.  Empty the repository (Repository Administrator ->Repository -> General -> Data Storage Settings -> Empty 
   
2. Set the repository to “Offline” (Repository Administrator -> General -> Identity -> Offline  
   

Partial Repository Move 

There are three methods for moving a portion of a QualiWare repository such as a model, set of models, specific object templates, etc. 

1. Using QLM (QualiWare Lifecycle Manager) File-> Import and Export -> Export a Subset 
   
   Specify the set of models, objects, etc. to be exported from the source repository and whether to include linked objects. This will create a .QRX file which may be imported into a target repository using QLM.  
   Please Note that only the current default version of a model, or object may be exported. Previous versions are considered repository history and cannot be exported in this manner.  
    
2. Alternately using the QualiWare web client Repository Compare functionality, an authorized user may move content from a source repository to a pre-existing target repository in real time. The Repository Compare function also enables the creation of a list of models and/or objects and uses the QIS Scheduler to send the selected content to one or more repositories in “batch” mode.  
   
   Please note that only the current default revision of a model or object may be moved. Previous revisions are considered repository history and cannot be moved in this manner.  
   
   
3. QualiWare Command Language (custom code) may be used to move content between repositories (i.e., to separate or consolidate repository content). 

 

  

Database & Repository Setup 

It's best practice that when setting up a new server QIS\QEF\LOGS be in individual databases. It's also important for each Repository to be set up in it's own DB. Having all your repositories in one database has been known to cause issues with slowness and IO issues.  

QualiWare routinely publishes updates for the QIS/QEF database specification and configuration information which can be found on the QualiWare Center of Excellence. 

QCL Engine  

The QCL Engine is used primarily for auto-publishing content and is required for Web Publishing. If the QCL engine is not running, then changes that are made on the web will not roll back to the QLM sessions and vice versa.  

Private Workspaces  

Simply put, a Private Workspace (PWS) is a place where Architects and “Content Collaborators” can work without affecting the main (i.e., baseline) repository. There are mechanisms for promoting content from a Personal Workspace. CloseReach has a course specifically designed around the use of Governance and it's very helpful in planning and developing a proper Governance Workflow.  

It is recommended that in each repository you create a PWS (recommended naming “Private Workspace for Importing Content)” that allows people to import content so that it does not impact the main configuration. Once the content is validated it can then be promoted to the base, and then PWS can be emptied. A good example of when to use this type of configuration would be when importing Visio documents, where you only want to keep the important content. 

Text Search  

Text search provides the ability to search for content in the QualiWare repository. This feature will need to be turned on for each repository. To make Text Search available to end users, it must be activated as follows…  

Step 1.  Repository Administrator -> Repository -> Full-Text Search -> Edit  
 

Step 2. Repository Administrator -> Repository -> Service Operations -> Full-Text Search Index -> Recreate. This indexing process can take some time depending on the size of your database. 

 

Maintenance of Repositories 

Most of the repository maintenance is carried out in the Service Operations section of the QIS Repository Administrator.

Something to keep in mind is that most of the features requires that no one is connected to the repository.  Notifying your User Base before the maintenance and requesting that they close down QualiWare sessions to the repository is strongly recommended.  Another thing to remember is that the QCL Engine will have an active session running and will need to be stopped. 

Access Control 

It is strongly recommended that you use either AD groups or QualiWare groups to control access to your repositories. It can become a big burden on support if handling everything on an individual user basis. As an example, CloseReach recommends using Active Directory Group for setting up the collaboration group and using a QualiWare group for configuring the Architects.  

QualiWare Repository Roles 

QualiWare gives the ability to create Repository Roles in your organization in the QIS Repository Administrator. (Repository Roles are distinct from Administrative Roles, which are covered in a previous topic). It is a best practice to set this up using AD Groups or QualiWare Groups, to avoid adding users individually. These roles have an impact when setting up the web views so that the content can be filtered by role. Note that a given user may have more than one Repository Role available to them, depending upon the permissions resulting from their group membership. 

Repository Permissions 

Administrators 

CloseReach recommends having the QualiWare Administrators Group in each repository setup with all permissions, this will provide the administrators the ability to quickly troubleshoot any issues that may come up.  
 

All Users 

CloseReach recommends not using the “All Users” group in the repository as it will provide default permissions to everyone who has access. It's better to remove the “All Users” group then assign permissions by using QualiWare Groups that are named for the Repository that best reflects the use of the Repository.  An example of this would be, “RepositoryName-Standard Users”, “RepositoryName-Architects” and “RepositoryName-Plus”. This kind of configuration would allows you to control access to the repository, while at the same time being able to quickly identify a user’s access. 

• Note that you can use AD Groups and QualiWare Groups inside of QualiWare Groups. 

Using Deny Permissions 

CloseReach recommends not using the Deny Permission unless necessary. The logic behind this is that if a user is in multiple groups, the Deny permission is applied to one it will affect the user across all other group permissions.   

Using Grant Permissions   

Grant permission in QualiWare if the grant check mark is checked it will provide that access. If the Grant check mark is not checked in one group but is checked in another group, that user will still have access to that permission.  If the check mark is unchecked in all groups that user or group will not have that permission. 

Setting up Social Behavior Warehouse  

Installation instructions and configuration can be found the COE under the title Repositories-One Time Configuration of Repositories-Enabling and ConfigureSBW.pdf (Note to access  this PDF you need to be signed into the COE before clicking the link to access the document). It is recommended when setting up the SBW, that you use the same database as the repository is in but use a different schema.  

Setting up Governance Workflow Engine 

A meaningful description of the Governance Workflow Setup is beyond the scope of this paper. CloseReach has a Governance Workflow Engine (GWE) Course that goes into the details of how it works.  

It is recommended when setting up the Governance Workflow, that you use the same database as the repository is in but use a different schema. 

In the Repository Administrator, open the repository that you want to enable the Governance Workflow Engine and go to Addons. 
 

  

Once the Governance Workflow is enabled there are a few QRX files that need to be imported into the repository. They can be found in the models\Collaboration\Export files.