Guided Configuration - Pipelines
The Guided Configuration screen allows Administrators to configure LiveCompare for its first use, and to maintain an essential set of LiveCompare resources. It is displayed when an Administrator logs in to LiveCompare; and may be accessed by Administrators via the 
tool button in the LiveCompare Dashboard, or the 
tool button in the LiveCompare Studio.
Pipelines allow all the resources required for an impact analysis using the Smart Impact app to be stored together in a single object. A Pipeline stores the following:
-
The Analysis, Comparison, Usage and SAP Solution Manager System RFC Destinations to be used in the analysis.
-
An External Data Source containing a set of Business-Critical objects to be used by the Smart Impact app and Smart Impact Analysis workflow.
-
The Test Repositories to be searched to find test assets that match most-at-risk objects.
-
The Test Repository in which test requirements are to be created for most-at-risk objects that do not have matching test assets in the specified search Test Repositories.
-
The Test Repositories in which tests that match most-at-risk objects are to be executed.
-
The name of the test executions to be created in each Most-at-risk Execution Test Repository.
-
The path of the Test Repository folder in which tests are to be executed for each Most-at-risk Execution Test Repository.
-
The execution list path to reuse when creating test executions using the Create Test Execution action for each Most-at-risk Execution Test Repository.
The Pipelines tab lists the Pipelines defined on the LiveCompare server and allows you to create and maintain them. The Pipelines may be committed to prepare their resources so that you are ready to run the Smart Impact app, the LiveCompare Usage Report workflow, and workflows that populate the charts in the LiveCompare Dashboard.
Create Pipelines
To create a Pipeline, click 
to display the Pipeline dialog. Complete the fields as follows:
| Field | What to do |
|---|---|
| Name | Enter a unique name that will identify the Pipeline. |
| Description | Enter a description for the Pipeline. |
| Tester Business Critical | Select this checkbox to make impact analysis results based on this Pipeline more relevant to testers by marking objects that have associated tests as business critical. Impacted business critical objects that have associated tests will be identified as most-at-risk. |
RFC Destinations
This section stores the Pipeline’s RFC Destinations.
| Field | What to do |
|---|---|
| Analysis System | Select the RFC Destination for the Analysis System to be used in the Pipeline (required). |
| Comparison System | Select the RFC Destination for the Comparison System to be used in the Pipeline. |
| Usage System | Select the RFC Destination for the Usage System to be used in the Pipeline (required). |
| Solution Manager System | Select the RFC Destination for the Solution Manager System to be used in the Pipeline. |
Click 
if required to clear a field’s value.
Business Critical
This section stores the Pipeline’s Business Critical Objects External Data Source.
| Field | What to do |
|---|---|
| Business Critical Objects | Select an External Data Source with TYPE and NAME columns containing the set of Business Critical objects to be used by the Smart Impact app and Smart Impact Analysis workflow. Click if required to clear the field’s value. |
Search Test Repositories
This tab stores the Test Repositories that are to be searched to find test assets that match most-at-risk objects. Click 
to add a new Search Test Repository, and complete the fields as follows:
| Field | What to do |
|---|---|
| Name | Select a Test Repository to be searched. |
| Search Path | Optionally, specify a search path for this Test Repository in the Search Paths field, for example Subject/Release1. |
-
Click the
icon or press ENTER to save the entry; click the 
icon or press ESC to discard it. -
Click the
icon to or press ENTER to modify a saved entry; click the 
icon to delete it.
Repeat the above steps to add additional Search Test Repositories.
Execute Test Repositories
This tab stores the Test Repositories which tests that match most-at-risk objects are to be executed. Click to add a new Execute Test Repository, and complete the fields as follows:
| Field | What to do |
|---|---|
| Name | Select the Test Repository in which test runs for tests that match most-at-risk objects are to be created or executed. ALM, qTest and Tosca Test Repositories are available for selection, as these are supported by the Create Test Execution action. The selection is restricted to Search Test Repositories with types of Tosca, qTest or ALM. |
| Execution Name | Enter the name of the test execution to be created in the specified Test Repository. The test execution is created in a time-stamped folder named <Execution Name>_<YYYY-MM-DD HH:MM:SS>. If this field is not set, a time-stamped name of the form LiveCompare_<YYYY-MM-DD HH:MM:SS> is used as the default. |
| Execution Path | Enter the path to an existing Test Repository folder in which test executions are to be created and/or run, for example Execution/TestExecutions. If this field is not set, test executions will be created in the default Executions folder. |
| Execution List Path | For Tosca Test Repositories, enter a path to determine the location where the test executions will be created in the Tosca hierarchy. See below for details. |
| Test Events Path | For Tosca Test Repositories, enter a path to specify a folder where Test Events will be created, for example /MyFolder/Execution/TestEvents. If this field is not set, /Execution/TestEvents is used as the default. |
| Options |
Select ‘Create Test Runs’ to create test runs in the specified Execution Path folder, or ‘Create and Run Test Runs’ to create and execute the test runs. ‘Create and Run Test Runs’ is supported for Tosca Test Repositories only. If ‘Create and Run Test Runs’ is selected, the execution is performed using a Tosca configuration object that is managed using DEX (Tricentis Distributed Execution Engine). |
-
Click the
icon or press ENTER to save the entry; click the icon or press ESC to discard it. -
Click the
icon to or press ENTER to modify a saved entry; click the icon to delete it.
Repeat the above steps to add additional Execute Test Repositories.
Execution List Path field
For Tosca Test Repositories, the Execution List Path field may be used to determine the location where the test executions will be created in the Tosca hierarchy. For example, this allows all the test executions created by LiveCompare to be stored in their own execution list folder. The following table shows the outcomes of various Execution List Path settings.
| Execution list path | Outcome |
|---|---|
| <empty> | The default structure using the specified Execution Name and a timestamp is created in the /Executions folder. The /Executions folder must already exist. |
| Path to an execution list | LiveCompare reuses the execution list. Execution entries are created only for test cases that are not already in the execution list. |
| Path to an execution list folder | LiveCompare creates a uniquely named execution list in the execution list folder, and then creates test executions in the execution list. |
| Path to a folder | LiveCompare creates a uniquely named execution list folder, and then a uniquely named execution list. Note that the folder must be of a type that allows execution list folders to be created. If it isn’t, LiveCompare will create the default structure as described in the <empty> outcome. |
| Path to another kind of object | LiveCompare will create the default structure as described in the <empty> outcome. |
Requirements Test Repository
This tab stores the Test Repository in which test requirements are to be created for most-at-risk objects that do not have matching test assets in the specified search Test Repositories. Complete the fields as follows:
| Field | What to do |
|---|---|
| Name | Select the Test Repository in which test requirements are to be created for most-at-risk objects that do not have matching test assets in the specified search Test Repositories. qTest and Tosca Test Repositories are available for selection, as these are supported by the Create Test Requirements action. Tosca, qTest and ALM Test Repositories are supported. |
| Requirements Path | Enter the name of an existing folder in which test requirements are to be created. Items in the path should be separated with a ‘/’. If this field is not set, ‘Requirements’ is used as the default (optional). |
When the Pipeline’s fields have been completed, click the ‘Save’ button to create the Pipeline. When a Pipeline is saved, LiveCompare discards any Search Test Repositories or Execute Test Repositories that have an empty Name field.
Edit Pipelines
To edit a Pipeline, click the 
icon in the Actions column for the corresponding row in the Pipelines tab. The Pipeline screen is displayed. Modify the fields as described above and click the ‘Save’ button to save your changes. When a Pipeline is saved, LiveCompare discards any Search Test Repositories or Execute Test Repositories that have an empty Name field.
Delete Pipelines
To delete a Pipeline, click the 
icon in the Actions column for the corresponding row in the Pipelines tab. A confirmation dialog is displayed.
Note that when a Pipeline is deleted, none of its RFC Destinations or Test Repositories are deleted, however, it is removed from all resource groups of which it is a member. Deleting a Pipeline also deletes its Pipeline workspace, used in the Commit Configuration process described below.
Commit a configuration
Click ‘Commit Configuration’ to prepare the resources in each of your Pipelines so that you are ready to run the Smart Impact app and the LiveCompare Usage Report workflow.
Click the help link in the Guided Configuration - Pipelines screen before clicking ‘Commit Configuration’ if you have upgraded from LiveCompare 4.8 or earlier, or if you have not used Guided Configuration before. The help topic explains how to look for scheduled activities that may be replaced with Guided Configuration. The link is not shown if the Commit Configuration process has already been run.
When you click ‘Commit Configuration’, the following happens. Note that the Learning Pipeline created as part of the Smart Impact Learning app is not processed when the ‘Commit Configuration’ process is run.
A workspace is created for each Pipeline
A workspace is created for each Pipeline. The workspace is named __Pipeline_<Pipeline Name>_<Identifier>. A global workspace named __Global_Confguration_<Identifier> is also created.
A workspace is created for each Object Links Cache database
A workspace is created for each distinct Analysis System in the Pipelines. Each workspace is named __Create Object Links Cache_<RFC Destination Name>_<Identifier>.
A workspace is created for each Test Repository cache
A workspace is created for each distinct Test Repository in the Pipelines. Each workspace is named __Create Test Repository Cache_<Test Repository Name>_<Identifier>.
The workspaces are populated
The following template workflows (and their dependent workflows) are copied to each Pipeline workspace:
The following template workflow (and its dependent workflows) is copied from the Guided Configuration templates folder to each Create Object Links Cache workspace:
The following template workflow (and its dependent workflows) is copied from the Guided Configuration templates folder to each Create Test Repository Cache workspace:
The LiveCompare Usage Report workflow is copied to the global workspace.
The workflows are configured
In each Pipeline workspace, the following workflows are configured to use the appropriate Pipeline:
| Workflow | What does it use? |
|---|---|
| Configurator Impact Analysis | The Pipeline’s RFC Destinations and Test Repositories. |
| Developer Impact Analysis | The Pipeline’s RFC Destinations. |
| Security Impact Analysis | The Pipeline’s RFC Destinations. |
In each Create Object Links Cache workspace, the Create Object Links Cache workflow is configured to use the appropriate Analysis and Usage systems.
In each Create Test Repository Cache workspace the Create Test Repository Cache workflow is configured to use the appropriate Analysis Systems, Usage Systems and Search Paths.
The Configurator Impact Analysis, Developer Impact Analysis and Security Impact Analysis workflows are configured to send emails to the Configuration, Development and Security email addresses set in the Guided Configuration - Email screen.
In the global workspace, the LiveCompare Usage Report workflow is configured to send emails to the Usage address set in the Guided Configuration - Email screen, and to Tricentis if the ‘Do Not Send Anonymous Usage Data to Tricentis’ switch is turned off.
The workflows are scheduled
In each Pipeline workspace, the workflows are scheduled to run as follows.
| Workflow | When does it run? |
|---|---|
| Developer Impact Analysis | Daily, starting at 04:00 and repeating every 4 hours. |
| Security Impact Analysis | Daily, starting at 05:00 and repeating every 4 hours. |
| Configurator Impact Analysis | Daily, starting at 06:00 and repeating every 4 hours. |
In each Create Object Links Cache workspace the Create Object Links Cache workflow is scheduled to run at weekly, each Saturday at 01:11.
In each Create Test Repository Cache workspace the Create Test Repository Cache workflow is scheduled to run at weekly, each Saturday at 02:09.
In the global workspace, the LiveCompare Usage Report workflow is scheduled to run weekly, each Monday at 07:00.
Note that the Developer Impact Analysis, Security Impact Analysis and Configurator Impact Analysis workflows, may not be successful unless an object links cache database is available for their Analysis Systems.
Performance history data is retrieved
The last 13 months of performance history data is retrieved immediately for each Pipeline’s Usage System in the Usage System’s PHD tab. A schedule is set to retrieve the last 13 months of performance history data, on the first day of each month at 01:00.
Daily usage audit data is retrieved
The last 13 months of Daily Usage Audit is retrieved immediately for each Pipeline’s Comparison System in the Comparison System’s DUA tab. A schedule is set to retrieve the last 13 months of Daily Usage Audit data, on the first day of each month at 01:00.
IMG data is download
IMG data is downloaded for each Pipeline’s Comparison system in the Comparison System’s IMG tab.
Monitor progress
The following status screen is displayed while the Commit Configuration process is running. Note that the process runs in the background, so you may access other LiveCompare screens during this time.
Press the F5 key periodically to update the display.
When the Commit Configuration process has finished, the Guided Configuration - Email screen is displayed. Click the Pipelines tab to display the following screen.
Note that when the Commit Configuration process has finished, the workflows that have been copied to Pipeline workspaces will still need to run according to their schedules. These may be monitored by selecting the Process Runs > Scheduled hierarchy folder in the LiveCompare studio.
Recommit a configuration
If the Commit Configuration process is run more than once, LiveCompare does the following for the second and subsequent runs:
-
It skips unchanged Pipelines.
-
It deletes workspaces for deleted Pipelines.
-
It deletes and recreates workspaces for changed Pipelines.
-
It downloads Performance History Data and Daily Usage Audit data for the Usage Systems in all Pipelines.
-
It downloads the IMG for the Analysis and Comparison Systems in all Pipelines.
Reset configuration
If a problem with the LiveCompare Application Server occurs while the Commit Configuration process is running, the Commit Configuration process may remain in the ‘Committing...’ state. In this case, an Administrator may reset the process by carrying out the following steps.
-
Click
to access the LiveCompare studio. -
Select the Administration folder in the LiveCompare hierarchy and choose ‘Reset Configuration’ from the context menu.
-
Click ‘Reset’ in the Details pane.
This resets the currently-running Commit Configuration process; however, any configuration work that has already been completed will remain unaffected. You should manually delete the workspaces generated by the Commit Configuration process (whose names begin with __Pipeline or __Create) before committing the configuration again.