WFM general 7.0.0.38 resolved issues
Total: 9 issues
----------------
WFM-31761
Data replication should replicate deleted records even if no updated records exist
The Data Replication task was updated to replicate deleted records even if there are no new inserted or updated records in a table.
----------------
WFM-31923
7.0.0x: System error occurred while running Balance Detail Report
A system error occurs while running the Balance Detail Report in Cognos.
Outcome
Fixed.
----------------
WFM-32358
Issue with replicating WB_DELETE_HISTORY and WBARCH_DELETE_HISTORY
When the WB_DELETE_HISTORY table contains more than 2 million new records, it takes too long to get all the data in a single query, resulting in a timeout during replication.
Outcome
Fixed by changing the algorithm to fetch and process the data in batch.
----------------
WFM-32421
Badge swiped on a clock over an existing user swipe activity displays consecutive type validation message
When a badge is swiped or entered on a clock over an existing user swipe activity, the clock displays the consecutive type validation message. Two swipes (accepted and rejected) are saved to the clock with the same timestamp. Both swipe entries are for the badge that was swiped (or entered) first and not the badge that was scanned over an existing swipe activity.
Outcome
Fixed. The badge consumer is disabled while displaying the validation message.
----------------
WFM-32472
Embedded Clock Enhancement: Show message to indicate clock is waiting for response from WFM
After enabling swipe sharing across clocks, all the readers in the group that share swipes appear to freeze whenever any swipe occurs.
To fix this issue, a "Validating swipe" message is now displayed for all embedded clocks if swipe sharing is enabled for the reader and the validation requires the last swipe. The timeout of the message is the timeout of the swipe request + 500 milliseconds.
----------------
WFM-32863
Change data replication task to use multiple threads per table
The Data Replication task has been updated to apply multiple threads to replicate one table. This resulted in a performance gain of about 25%. Previously, only one thread could process a table, resulting in a bottleneck for large tables during the initial replication.
----------------
WFM-32864
Change how incremental data replication selects changed data
For incremental replication, the queries have been refactored to query only for changed records using the _UTC_UPDATE_DATE index. Previously, the number of queries was proportional to the number of records in the table, regardless of the number of records that have actually been changed.
----------------
WFM-32865
Archive table not replicated when there is no data in workbrain table to replicate
When there is no data to replicate in a WFM table (for example, Employee_Team), its archive table (archive.Employee_Team) does not get replicated.
Outcome
Fixed.
----------------
WFM-33020
Profile data replication task
After profiling the Data Replication task, these changes were implemented to improve performance:
- Caching the BeanDescription for each type of domain object. This change showed a 50% reduction in serialization time when testing 500 batches of 2000 docket objects. An initial replication test using non-production size data showed results that were 10% faster.
- Replacing the regex pattern that was used to match field names containing "Utc" and "Date" with two calls to String.indexOf. This change showed significant improvement in reducing overhead, which adds up when processing a large amount of data.
----------------