|
5 | 5 | <!--./gh-md-toc --insert /path/to/README.md--> |
6 | 6 | <!--ts--> |
7 | 7 | * [Advanced topics](#advanced-topics) |
| 8 | + * [Access conditions from the CCDB](#access-conditions-from-the-ccdb) |
| 9 | + * [Definition and access of task-specific configuration](#definition-and-access-of-task-specific-configuration) |
| 10 | + * [Custom QC object metadata](#custom-qc-object-metadata) |
8 | 11 | * [Data Inspector](#data-inspector) |
9 | 12 | * [Prerequisite](#prerequisite) |
10 | 13 | * [Compilation](#compilation) |
|
13 | 16 | * [Use MySQL as QC backend](#use-mysql-as-qc-backend) |
14 | 17 | * [Local CCDB setup](#local-ccdb-setup) |
15 | 18 | * [Local QCG (QC GUI) setup](#local-qcg-qc-gui-setup) |
16 | | - * [Custom QC object metadata](#custom-qc-object-metadata) |
17 | | - * [Access conditions from the CCDB](#access-conditions-from-the-ccdb) |
18 | 19 | * [Information Service](#information-service) |
19 | 20 | * [Usage](#usage) |
20 | 21 | * [Configuration files details](#configuration-files-details) |
|
26 | 27 |
|
27 | 28 | [← Go back to Modules Development](ModulesDevelopment.md) | [↑ Go to the Table of Content ↑](../README.md) | [Continue to Frequently Asked Questions →](FAQ.md) |
28 | 29 |
|
| 30 | +## Access conditions from the CCDB |
| 31 | + |
| 32 | +The MonitorObjects generated by Quality Control are stored in a dedicated |
| 33 | +repository based on CCDB. The run conditions, on the other hand, are located |
| 34 | +in another, separate database. One can access these conditions inside a |
| 35 | +Task by a dedicated method of the TaskInterface, as below: |
| 36 | +``` |
| 37 | +TObject* condition = TaskInterface::retrieveCondition("Path/to/condition"); |
| 38 | +if (condition) { |
| 39 | + LOG(INFO) << "Retrieved " << condition->ClassName(); |
| 40 | + delete condition; |
| 41 | +} |
| 42 | +``` |
| 43 | +Make sure to declare a valid URL of CCDB in the config file. Keep in |
| 44 | + mind that it might be different from the CCDB instance used for storing |
| 45 | + QC objects. |
| 46 | + |
| 47 | +``` |
| 48 | +{ |
| 49 | + "qc": { |
| 50 | + "config": { |
| 51 | + ... |
| 52 | + "conditionDB": { |
| 53 | + "url": "ccdb-test.cern.ch:8080" |
| 54 | + } |
| 55 | + }, |
| 56 | + ... |
| 57 | +``` |
| 58 | + |
| 59 | +## Definition and access of task-specific configuration |
| 60 | + |
| 61 | +A task can access custom parameters declared in the configuration file at `qc.tasks.<task_name>.taskParameters`. They are stored inside a key-value map named mCustomParameters, which is a protected member of `TaskInterface`. |
| 62 | + |
| 63 | +One can also tell the DPL driver to accept new arguments. This is done using the `customize` method at the top of your workflow definition (usually called "runXXX" in the QC). |
| 64 | + |
| 65 | +For example, to add two parameters of different types do : |
| 66 | +``` |
| 67 | +void customize(std::vector<ConfigParamSpec>& workflowOptions) |
| 68 | +{ |
| 69 | + workflowOptions.push_back( |
| 70 | + ConfigParamSpec{ "config-path", VariantType::String, "", { "Path to the config file. Overwrite the default paths. Do not use with no-data-sampling." } }); |
| 71 | + workflowOptions.push_back( |
| 72 | + ConfigParamSpec{ "no-data-sampling", VariantType::Bool, false, { "Skips data sampling, connects directly the task to the producer." } }); |
| 73 | +} |
| 74 | +``` |
| 75 | + |
| 76 | +## Custom QC object metadata |
| 77 | + |
| 78 | +One can add custom metadata on the QC objects produced in a QC task. |
| 79 | +Simply call `ObjectsManager::addMetadata(...)`, like in |
| 80 | +``` |
| 81 | + // add a metadata on histogram mHistogram, key is "custom" and value "34" |
| 82 | + getObjectsManager()->addMetadata(mHistogram->GetName(), "custom", "34"); |
| 83 | +``` |
| 84 | +This metadata will end up in the CCDB. |
| 85 | + |
29 | 86 | ## Data Inspector |
30 | 87 |
|
31 | 88 | This is a GUI to inspect the data coming out of the DataSampling, in |
@@ -108,45 +165,6 @@ At the moment, the description of the REST api can be found in this document : h |
108 | 165 |
|
109 | 166 | To install and run the QCG locally, and its fellow process tobject2json, please follow these instructions : https://github.com/AliceO2Group/WebUi/tree/dev/QualityControl#run-qcg-locally |
110 | 167 |
|
111 | | -## Custom QC object metadata |
112 | | - |
113 | | -One can add custom metadata on the QC objects produced in a QC task. |
114 | | -Simply call `ObjectsManager::addMetadata(...)`, like in |
115 | | -``` |
116 | | - // add a metadata on histogram mHistogram, key is "custom" and value "34" |
117 | | - getObjectsManager()->addMetadata(mHistogram->GetName(), "custom", "34"); |
118 | | -``` |
119 | | -This metadata will end up in the CCDB. |
120 | | - |
121 | | -## Access conditions from the CCDB |
122 | | - |
123 | | -The MonitorObjects generated by Quality Control are stored in a dedicated |
124 | | -repository based on CCDB. The run conditions, on the other hand, are located |
125 | | -in another, separate database. One can access these conditions inside a |
126 | | -Task by a dedicated method of the TaskInterface, as below: |
127 | | -``` |
128 | | -TObject* condition = TaskInterface::retrieveCondition("Path/to/condition"); |
129 | | -if (condition) { |
130 | | - LOG(INFO) << "Retrieved " << condition->ClassName(); |
131 | | - delete condition; |
132 | | -} |
133 | | -``` |
134 | | -Make sure to declare a valid URL of CCDB in the config file. Keep in |
135 | | - mind that it might be different from the CCDB instance used for storing |
136 | | - QC objects. |
137 | | - |
138 | | -``` |
139 | | -{ |
140 | | - "qc": { |
141 | | - "config": { |
142 | | - ... |
143 | | - "conditionDB": { |
144 | | - "url": "ccdb-test.cern.ch:8080" |
145 | | - } |
146 | | - }, |
147 | | - ... |
148 | | -``` |
149 | | - |
150 | 168 | ## Information Service |
151 | 169 |
|
152 | 170 | The information service publishes information about the tasks currently |
|
0 commit comments