The Integration Test Camp for IDS Components

Inter­na­tio­nal Data Spaces are com­plex. Many com­pon­ents, such as Con­nec­tors, DAPS or Apps need to inter­act cor­rect­ly. To veri­fy the­se inter­ac­tions, deve­lo­pers exer­cise the soft­ware wit­hin a spe­ci­fic test envi­ron­ment. The Inte­gra­ti­on Test Camp is a remo­te­ly acces­si­ble infra­st­ruc­tu­re deve­lo­ped by IDSA mem­ber SQS. It gives com­pa­nies the oppor­tu­ni­ty to test the inter­ope­ra­bi­li­ty of pre-com­mer­cial IDSA com­pon­ents in a pro­duc­tion-like sce­n­a­rio.

The Inte­gra­ti­on Test Camp is open for ever­yo­ne as part of a mon­th­ly event, which is usual­ly announ­ced two weeks befo­re. Par­ti­ci­pants are given a two-hour time slot during which the ent­i­re infra­st­ruc­tu­re is avail­ab­le and reser­ved for them. During this time, the par­ti­ci­pants are in con­stant com­mu­ni­ca­ti­on with the SQS team. Video calls allow both par­ties to see and share what is hap­pe­ning. Gui­de­li­nes for the ses­si­ons spe­ci­fy each indi­vi­du­al test step.

Step by step to a trusted IDS infrastructure

The goal is to build a test archi­tec­tu­re that inclu­des all com­pon­ents of the IDS eco­sys­tem. To achie­ve this goal, SQS is taking a step-by-step approach: First, the basic archi­tec­tu­re was deve­lo­ped. In each edi­ti­on of the Inte­gra­ti­on Test Camp, new ele­ments are added to this basic archi­tec­tu­re.

In the archi­tec­tu­re deve­lo­ped for the First Inte­gra­ti­on Test Camp the­re were:

  1. Con­nec­tors based on the Trus­ted Con­nec­tor from Fraun­ho­fer AISEC, sup­por­ting IDSCP com­mu­ni­ca­ti­on pro­to­col, instal­led in SQS faci­li­ty. Some acted as pro­vi­ders and others as con­su­mers. The­re was also DIVA con­nec­tor from Fraun­ho­fer ISST, sup­por­ting HTTP com­mu­ni­ca­ti­on pro­to­col and acting as pro­vi­der, instal­led in SQS faci­li­ty.
  2. Three dif­fe­rent data sources:
    1. Real tem­pe­ra­tu­re sen­sor, sen­ding a float with the tem­pe­ra­tu­re mea­su­re every five seconds
    2. Real motor making ran­dom move­ments, sen­ding a json with the move­ments made every five seconds
    3. Then we have a way to send Con­trol­led data using Test­Work­Flow, a tool SQS deve­lo­ped, able to send any type of data par­ti­ci­pants need in a con­trol­led way
  3. A Bro­ker and a DAPS were offe­red as a ser­vice.

With this archi­tec­tu­re, the par­ti­ci­pants were able to test the inter­ope­ra­bi­li­ty bet­ween con­nec­tors, main­ly the hand­shake.

In the second edi­ti­on of the Inte­gra­ti­on Test Camp, a DAPS have been instal­led in the SQS faci­li­ty that was deve­lo­ped by Orbi­ter. The DAPS was pro­gram­med for test cases and repres­ents the Meta-DAPS in the test design. It logs errors and enab­les par­ti­ci­pants to estab­lish com­pa­ti­ble com­mu­ni­ca­ti­on bet­ween the con­nec­tors. Orbi­ter pro­vi­des the ent­i­re tech­ni­cal sys­tem inclu­ding log­ging and inter­ac­ti­ve para­me­ter input for SQS to test dif­fe­rent cases. Fur­ther­mo­re, Ger­man Edge Cloud pro­vi­ded a con­nec­tor that sup­ports the HTTP com­mu­ni­ca­ti­on pro­to­col. With this archi­tec­tu­re, the par­ti­ci­pants were not only able to test the inter­ope­ra­bi­li­ty bet­ween con­nec­tors, but also to test cer­ti­fi­ca­tes and the Dyna­mic Attri­bu­te Token manage­ment.

Integration Test Camp actual architecture

For the next edi­ti­on, a Bro­ker will be instal­led in the SQS faci­li­ty, and par­ti­ci­pants will be able to also test regis­tra­ti­on at a bro­ker and sear­ching of other con­nec­tors infor­ma­ti­on. After each edi­ti­on, SQS publis­hes a set of test cases that could be used as refe­rence for Inter­ope­ra­bi­li­ty Tes­ting.

If you would like to par­ti­ci­pa­te also, plea­se con­ta­ct idsa_qaas@sqs.es to recei­ve all infor­ma­ti­on that are nee­ded for the regis­tra­ti­on and pre­pa­ra­ti­on.