Verify Installation Correctness

4 minutes to read

Now that we have followed the installation instructions, are we ready for the developer handoff? To answer this question in the affirmative, it makes sense to run a few simple tests to ensure that our services are installed and configured properly.

Simple availability test

The simplest test you can run is to ping a URL and see if it returns a successful response. Ideally, this URL should not require any parameters or authorization, and its payload should be tiny.

All Customer's Canvas back-end services have a special endpoint that returns the information about the service - such as the version, build date, etc. It is a perfect candidate for the availability test.

Let's consider the Asset Storage service. Imagine that you have installed it at https://example.com/asset-storage. All you need to do is send the HEAD request to the api/v1/info endpoint.

curl --head https://example.com/asset-storage/api/v1/info

If you get a 200 OK response, the service is up and running.

The same will work for the Asset Processor and Design Atoms API services as well.

If you have some health monitoring system like Azure AppInsights, Zabbix or similar, it is a good idea to check the availability of a service with the help of this URL.

Tip

This endpoint supports not only HEAD, but also GET HTTP, so you can just open this URL in a browser. If you see a JSON with the version, build date, and other info, it means the test was successful. However, in scripts that check this URL on a regular basis, we recommend checking the HEAD version because it does not have a payload.

Integration test

As you might have noticed during installation and configuration, Customer's Canvas consists of multiple components. Even if each individual component is functioning properly, there are still too many moving parts. Checking on how all of them are working together is a good idea.

Asset Storage and MongoDB

Asset Storage needs a MongoDB availability. If the MongoDB address is incorrect, a connection string is malformed or the user does not have enough permissions to create records in it, the system won't work.

The easiest way to make sure that the Asset Storage can write data to MongoDB is to create a tenant, because unlike other entities, you don't have to upload any files. It can be done with a POST request to the /api/storage/v1/tenants endpoint.

Unlike the previous test, this operation does require an authorization. For our purposes, the API Key you have specified in the service AppSettings.config will work great. Just pass it through the X-Api-Key header as follows:

curl http://example.com/asset-storage/api/storage/v1/tenants -is \
    --data '{"name":"Test Tenant", "id": 4200042}' \  
    --header "Content-Type: application/json" \
    --header "X-Api-Key: YOUR_SECURE_API_KEY_FROM_APPSETTINGS"

You should get 201 Created status. If you have configured it to use along with Azure Blob Storage, don't worry if this request takes a while - provisioning an Azure Storage account does take some time.

Note

Be sure to specify the id field that does not exist (although on a fresh system, no tenants exist yet).

After you finish, it is necessary to clean up. Let's finish all other tests first and then remove all the data together. This process will be explained in the end.

Asset Storage and Asset Processor connection

Customer's Canvas services communicate with each other. In particular, all services rely heavily on the Asset Storage, and you must set a URL and API Key for this service in other services configurations. If you have any typos there, you may run into some hard-to-identify issues.

To ensure that the Asset Processor recognizes the Asset Storage, you can try to import an image. Prepare any JPEG or PNG file (e.g. by taking a screenshot) and make a POST request to api/processor/v1/images/import?tenant_id.

curl http://example.com/asset-processor/api/procesor/v1/images/import?4200042 \
    -F "sourceFile=@./test.jpg" 
    -H "X-Api-Key: YOUR_SECURE_API_KEY_FROM_APPSETTINGS" -i

You should get 201 Created status and the JSON containing an ID of a created image item. Remember this ID for the next test and for the clean-up process (see the last section).

Asset Storage and Design Atoms API connection

The same is correct for the Design Atoms API service. Let's use the image we have just uploaded in another request to the Design Atoms API.

Let's say the image ID was 5f92db76a06363683f37d753. The test request to Design Atoms API would look like this:

curl http://example.com/design-atoms-api/api/atoms/v1/units/4200042/itemCreator -is \ 
    --data 'sourceType=ImageStorage&sourceId=5f92de37a06363683f37d755' \
    --header "X-Api-Key: YOUR_SECURE_API_KEY_FROM_APPSETTINGS"

The 200 OK indicates that it works fine.

Clean-up process

You don't want to keep the test data in the production environment. In our example, we have created two things - the file with the ID 5f92db76a06363683f37d753 and a tenant with the ID 4200042. Let's clean up.

To delete the file, use this request. Draw attention to the tenant ID passed through the query string:

curl http://example.com/asset-storage/api/storage/v1/images/5f92db76a06363683f37d753?4200042 --request DELETE -is \ 
     -H "X-Api-Key: YOUR_SECURE_API_KEY_FROM_APPSETTINGS"

If you get 200 OK status, let's proceed to the next step and delete the tenant:

curl http://example.com/asset-storage/api/storage/v1/tenants/4200042 --request DELETE -is \ 
     -H "X-Api-Key: YOUR_SECURE_API_KEY_FROM_APPSETTINGS"

The system is now clean and you can be pretty sure that the system is configured and running as expected.

In the next section, we will discuss how to connect the Design Editor to the Customer's Canvas back-end services and ensure that it works with the data managed inside BackOffice.