DELETE FROM TENANT.BLC_NOTIFICATION_STATE where ENTITY_TYPE = 'com.broadleafcommerce.tenant.provider.jpa.domain.JpaTenantApplication' AND NOTIFICATION_NAME = 'PERSISTENCE'
- v1.0.0-latest-prod
Change in functionality for local application synchronization & persistence
To enable new Application synchronization functionality, ApplicationDataRouteSupporting is added to AdminUserServices
Fixed bug where AdminUserApplicationJpaAutoConfiguration was duplicating data routing declarations from AdminUserJpaAutoConfiguration, causing conflicting behavior.
This change removes the existing JpaUserApplication entity/domain (and supporting components) and replaces them with the DataTracking-provided JpaApplication domain and supporting components.
This brings the Admin User service in-line with other Broadleaf microservices that leverage the DataTracking tenant synchronization behavior.
AdminUserContextRequestHydrator was removed and the DefaultContextRequestHydrator from DataTracking will now be used.
ApplicationPersistenceHandler was removed and the TenantPersistenceHandler from DataTracking will now be used.
TenantSyncPersistenceConsumer was removed along with the messaging channel.
ApplicationService was removed and replaced by retrieving Applications from ContextInfo. Any uses can be migrated to CommonApplicationService from DataTracking.
ApplicationRepository was removed. Any uses can be migrated to CommonApplicationRepository from DataTracking.
AdminUserApplicationRepository was removed.
Before starting up again, we recommend executing the following 2 SQL scripts against TenantServices' schema to make sure data is synchronized as the application starts.
The SQL scripts intend to cause TenantServices to re-emit PersistenceMessages for all of its current existing JpaTenantApplication entities.
These are expected to be consumed by the new version of AdminUserServices such that TenantPersistenceHandler will naturally populate its local JpaApplication tables with those applications.
|
Warning
|
If your project has any customizations around Tenant’s Application domain or Notification States, the migration steps may need to be updated to reflect that. |
First, it helps to remove any previous NotificationStates for persisting applications, as they might conflict with the next step.
DELETE FROM TENANT.BLC_NOTIFICATION_STATE where ENTITY_TYPE = 'com.broadleafcommerce.tenant.provider.jpa.domain.JpaTenantApplication' AND NOTIFICATION_NAME = 'PERSISTENCE'Now, add a new NotificationState for all of its existing Applications to cause TenantServices to emit new PersistenceMessages once it is running.
Note: The concatenated prefix + id may be longer than allowed by your schema’s ID column size. In that circumstance, adjust the prefix to ensure uniqueness while not exceeding the size limit.
INSERT INTO TENANT.BLC_NOTIFICATION_STATE (ID, CONTAINER, ENTITY_TYPE, CHANGE_TIMESTAMP, CHANGE_TIMESTAMP_ACK, ACKED, STOPPED,
ATTEMPTS, NEXT_ATTEMPT, NOTIFICATION_NAME, MESSAGE_TYPE, MESSAGE_VALUE)
SELECT concat('prefix_', id::VARCHAR), id, 'com.broadleafcommerce.tenant.provider.jpa.domain.JpaTenantApplication', '1970-01-01 00:00:00.000', NULL, 'N', 'N',
0, NULL, 'PERSISTENCE', NULL, NULL
FROM TENANT.BLC_TENANT_APPLICATION;