-
Notifications
You must be signed in to change notification settings - Fork 2
Adding a new target
This page describes how a new provider can be added to the test suite so that the basic test scenarios TS01 to TS07 can be run for a different target site. This involves some advanced programming of the cdab-client software.
You should have the cdab-client .NET solution ready, preferably with Visual Studio Code and .NET SDK 7.0 installed. See the Building the test suite page for all the details.
Adding a new target means adding some C# code to the cdab-client and to adjust a configuration file. The code for the existing DIAS providers is part of an external library, but new code can easily be integrated in the main solution.
This section gives the overview of the tasks.
Usually, the following interfaces have to be implemented:
- An instance of
IDataHubSourceWrapper
. This class will be the main access point for the cdab-client combining all top-level functionality of the target site. - An implementation of
IOpenSearchable
. This class will implement the data sourcing and mainly provide functionality for issuing queries and processing the results. - An implementation of the abstract class
OpenSearchRequest
. This class will contain the low-level functionality for making a query to the data source.
Depending on the complexity of the provider's interface it can make sense to have additional classes (e.g. API client classes and DTO classes for API messages), however the above three are the core classes.
Furthermore, the TargetSiteWrapper
class needs to be changed so that the new wrapper class is instantiated when the cdab-client is used with a configuration for that new target site. The TargetSiteWrapper
class is found in TargetSiteWrapper.cs.
For the specific classes to be implemented there is the SampleTarget folder with a functioning example for two different types of data source API.
The cdab-client relies on a configuration file, and such a file is provided for testing purposes in config.sample.yaml. The file needs adjustments before the tests.
All these tasks are described in more details below. There are also comments directly in the files that need to be changed.
The wrapper class is central to the entire development that is described in this guide. It will provide the top-level access to the functionality of the target site that is used by the cdab-client. It will be instantiated at the beginning of each test scenario execution and take care of
- Performing the queries to the target site's catalogue
- Providing download access for the products
- Enabling the ordering of products (optional)
- Accessing storage functionality (optional)
The IDataHubSourceWrapper
contains the following members (explained in table below):
public interface IDataHubSourceWrapper
{
string Name { get; }
DataHubWrapperSettings Settings { get; }
HttpWebRequest CreateAvailabilityTestRequest();
IOpenSearchable CreateOpenSearchable(OpenSearchableFactorySettings settings);
IAssetAccess GetEnclosureAccess(IOpenSearchResultItem item);
void AuthenticateRequest(HttpWebRequest request);
IAssetAccess OrderProduct(IOpenSearchResultItem item);
IAssetAccess CheckOrder(string orderId, IOpenSearchResultItem item);
IStorageClient CreateStorageClient();
IDataHubSearchClient Search(string key);
ISentinelDataClient ForProduct(ISentinelProduct data);
}
Property/Method | Name | Purpose | Needed for scenario |
---|---|---|---|
P | Name | A short name of the target site | TS01-TS07 |
P | Settings | Contains configuration settings | TS01-TS07 |
M | CreateAvailabilityTestRequest() | Simple test to check target site's basic availability | TS01 |
M | CreateOpenSearchable(...) | Returns an IOpenSearchable instance |
TS01-TS06 |
M | GetEnclosureAccess(...) | Gets an object that can download a resource | TS01-TS04, TS07 |
M | AuthenticateRequest(...) | Adds authentication information to a download request if necessary | TS01-TS04 |
M | OrderProduct(...) | Creates an order for an offline product | TS04 |
M | CheckOrder(...) | Checks the status of a previously created order | TS04 |
M | CreateStorageClient() | TS07 | |
M | Search(...) | - | |
M | ForProduct(...) | - |
The last two methods don't have to be implemented (the NotImplementedException
can be thrown).
There are two main types of data sources (or catalogues):
- OpenSearch-compatible catalogues: If the data source supports the OGC OpenSearch API that returns ATOM feeds, the development is relatively simple and existing functionality can be reused.
- Proprietary catalogues: For other types of data sources, an OpenSearch requests have to be translated into API requests accepted by the provider and an ATOM result has to be returned. This is somewhat more complicated.
To make this case work, adjust three files in the SampleTarget folder:
- In SampleOpenSearchRequest, adjust the
GetResponse
method. - In SampleOpenSearchable, adjust the
GetOpenSearchParameters
andCreate
methods. - In SampleWrapper, adjust the various members described above according to the offers of the target site and the test scenarios to be implemented. Make sure to return a
SampleOpenSearchable
instance inCreateOpenSearchable
.
There are comments in the code helping to identify the crucial sections.
The work to be done is fundamentally the same as in the OpenSearch case. Adjust three files in the SampleTarget folder:
- In SampleVirtualOpenSearchRequest, adjust the
GetResponse
method. - In SampleVirtualOpenSearchable, adjust the
GetOpenSearchParameters
andCreate
methods. - In SampleWrapper, adjust the various members described above according to the offers of the target site and the test scenarios to be implemented. Make sure to return a
SampleVirtualOpenSearchable
instance inCreateOpenSearchable
.
In TargetSiteWrapper.csTargetSiteWrapper.cs), you have to make sure that the proper Wrapper class (SampleWrapper
) is used.
- In the
InitType
method, return the appropriate type, which defines which test scenarios are enabled. You can useTargetType.DIAS
in order to enable all test scenarios (scenarios that are not applicable can simply be skipped). The type is based on the target site's service URL from the configuration file, but for simplicity, you can remove the other providers and always returnTargetType.DIAS
. - In the
CreateDataAccessWrapper
method, make sure thatSampleWrapper
instance is returned. The returned wrapper is based on the target site's service URL from the configuration file, but for simplicity, you can remove the other providers and always return aSampleWrapper
instance.
The configuration file config.test.yaml contains a single provider that can be used as the configuration for the new target site.
Under that node, you shoud adjust the data.url
key and remove collections that are not supported.
With all these changes done, you can build and run a test using the following command (the last argument is the test scenario to be run):
dotnet run --project src/cdab-client/cdab-client.csproj -- --conf config.yaml -v -tsn=Local -lf=1 -tn=test TS01