Item Registration Service

Migration to v3.9.0

Service 2 Service Authentication

Add - new API path:

The "service 2 service" feature has been introduced in this version of the Item Registration Service. From now on, the Item Registration Service is only able to validate service tokens (client/operator tokens are no longer validated). The validation of all kinds of client/operator tokens now happens in the API gateway, therefore the new API path has been introduced (/api/basket-item-registration) and must be used by all clients (Basket Authorization and Authentication).

Add - new base roles:

A new set of base roles has been introduced for the Item Registration Service. Every client calling the Item Registration Service needs the required base role for the called endpoint either in its service token or passport (if it is the first service in the call chain). The new base roles start with "b:basket.reg".

Remove - "tenantId" as a variable in the base path (url):

Resolving the "tenantId" out of the request URL of an incoming request has been removed by changing the security lib (AppKit to cloud platform). The tenantId must be provided by the caller via an http header (GK-Tenant-Id) or in the passport.

Section in the API Guideline: Using tenantId as a variable in the base path does not work well with the API gateway. Therefore, new service APIs must not use tenantId as a path. The tenantId must be taken from JWT (transformed by the API gateway into GK Passport) or the GK-Tenant-Id header.

Migration to v2.12.0

Configuration Changes

A lot of configurations have been moved from the Storemanager template to application.yaml (e.g. client-side 'Basic Auth' credentials are automatically set to cluster secret values and do not need to be configured in the SM template).

Removed application.yaml (New) Description
## Basket Service

gkr.item-registration-service.remote-client.basket.url

gkr.item-registration-service.remote-client.basket.connectTimeout

gkr.item-registration-service.remote-client.basket.readTimeout

core.common.security.client.http.auth.group.basket-service.type

core.common.security.client.http.auth.group.basket-service.BASIC.username

core.common.security.client.http.auth.group.basket-service.BASIC.password

 
irs:
remote-services:
basket-service:
url: http://basket-service:8080/basket-service
read-timeout: 31000
connection-timeout: 30000
max-conn-per-route: 150
max-conn-total: 150
authentication:
username: item-registration-service
password:
 No manual config change in the cluster needed. URLs are set to cloud-internal URLs and credentials are filled with values from cluster secrets.
## SDC

gkr.item-registration-service.remote-client.sdc.url

gkr.item-registration-service.remote-client.sdc.connectTimeout

gkr.item-registration-service.remote-client.sdc.readTimeout

core.common.security.client.http.auth.group.sdc.type core.common.security.client.http.auth.group.sdc.BASIC.username core.common.security.client.http.auth.group.sdc.BASIC.password

 
irs:
remote-services:
sdc:
url: http://sdc:8080/sdc
read-timeout: 31000
connection-timeout: 30000
max-conn-per-route: 150
max-conn-total: 150
authentication:
username: item-registration-service
password:
 No manual config change in the cluster needed. URLs are set to cloud-internal URLs and credentials are filled with values from cluster secrets.
## Transaction Pool

gkr.item-registration-service.remote-client.tx-pool.url

gkr.item-registration-service.remote-client.tx-pool.connectTimeout

gkr.item-registration-service.remote-client.tx-pool.readTimeout

core.common.security.client.http.auth.group.transaction-pool.type

core.common.security.client.http.auth.group.transaction-pool.BASIC.username

core.common.security.client.http.auth.group.transaction-pool.BASIC.password

 
irs:
remote-services:
transaction-pool:
url: http://sdc:8080/sdc
read-timeout: 31000
connection-timeout: 30000
max-conn-per-route: 150
max-conn-total: 150
authentication:
username: item-registration-service
password:
 No manual config change in the cluster needed. URLs are set to cloud-internal URLs and credentials are filled with values from cluster secrets.
# Caching

caching.cachingEnabled=true

caching.mbeansEnabled=true

caching.statisticsEnabled=false

# Cache BusinessUnit

caching.cache.BusinessUnit.expiration=4h

caching.cache.BusinessUnit.capacity=10000

# Cache BusinessUnitGroupID

caching.cache.BusinessUnitGroupID.expiration=4h

caching.cache.BusinessUnitGroupID.capacity=10000

# Cache PosUomItem

caching.cache.PosUomItem.expiration=4h

caching.cache.PosUomItem.capacity=10000

# Cache CurrencyRoundingRule

caching.cache.CurrencyRoundingRule.expiration=4h

caching.cache.CurrencyRoundingRule.capacity=10000

# Cache Reason

caching.cache.Reason.expiration=4h

caching.cache.Reason.capacity=10000

 
irs:
caching:
enabled: true
statistics-enabled: false
mbeans-enabled: false
caches:
BusinessUnit:
expiration: 4h
capacity: 10000
BusinessUnitGroupID:
expiration: 4h
capacity: 10000
PosUomItem:
expiration: 4h
capacity: 10000
CurrencyRoundingRule:
expiration: 4h
capacity: 10000
Reason:
expiration: 4h
capacity: 10000
 No manual config change in the cluster needed.
log4j-logging.propeties (complete file) 
logging:
level:
com.gk_software.gkr.basket.service: INFO
com.gksoftware.gkr.basket.engine: INFO
 Log settings can now be changed to "env" variables via helm chart values.

Example: values.yaml

extraEnvs:
- name: LOGGING_LEVEL_COM_GKSOFTWARE_GKR_BASKET_SERVICE
value: DEBUG
- name: LOGGING_LEVEL_COM_GKSOFTWARE_GKR_BASKET_ENGINE
value: DEBUG