mod-fqm-manager: Refactoring guide
Overview
This module includes additional critical updates for Eureka compatibility. Key differences focus on:
Adjustment of consortia scenarios
Increasing lifetime of
accessToken& removing additional logins invalidate-entity-typescenarios
Adjustment of consortia scenarios
Since most scenarios in the mod-fqm-manager/consortia was duplication of the common-consortia functionality, it was decided to make some adjustments of set-up related scenarios and use existing one.
Utility folder was removed, and common-consortia was added to pom.
As some capabilities creates in async way, and there is several minutes even after entitlement creation has status ‘finished’ it is still absent, it was decided not to make ‘sleep’ in the tests, but to make retry query for getting capabilities, while capabilities count won’t be same as expected. So, for now there is no opportunity to add all capabilities to the admins of consortia tenants. By default, all necessary capabilities is assigned to admin, so consortia could be set up. If some additional capabilities is needed to be assigned in scenarios, it must be done as in usual modules
Since we now using common-consortia functionality, here is changed part of set-up and destroy scenarios call.
Scenario: Create ['central', 'university'] tenants and set up admins
* call read('classpath:common-consortia/eureka/tenant-and-local-admin-setup.feature@SetupTenant') { tenant: '#(centralTenant)', tenantId: '#(centralTenantId)', user: '#(consortiaAdmin)'}
* call read('classpath:common-consortia/eureka/tenant-and-local-admin-setup.feature@SetupTenant') { tenant: '#(universityTenant)', tenantId: '#(universityTenantId)', user: '#(universityUser1)'}
....
Scenario: Destroy created ['university', 'central'] tenants
* call read('classpath:common-consortia/eureka/initData.feature@DeleteTenantAndEntitlement') {tenantId: '#(centralTenantId)'}
* call read('classpath:common-consortia/eureka/initData.feature@DeleteTenantAndEntitlement') {tenantId: '#(universityTenantId)'}Increasing lifetime of accessToken & removing additional logins in validate-entity-type scenarios
Since validate-entity-types scenario has a lot of steps and repeating login attempts, there was some unexpected errors during authorization process. We have implemented scenario, in common functionality, to increase lifetime of accessToken for created testTenant.
Now, after all steps of set-up scenario will be passed, the lifetime of the accessToken will be increased. Therefore login in each validation step was unnecessary, and was removed.
Scenario: create tenant and users for testing
Given call read('classpath:common/eureka/setup-users.feature')
* call read('classpath:common/eureka/keycloak.feature@configureAccessTokenTime') { 'AccessTokenLifespance' : 3600 }