In Syniti’s Master Data Management solution (MDM), the configuration of positions determines the Business Processes, Roles and Organization Units that users assigned to the position have access to. When a request is created, tables are populated with data that controls which users have access to the request and its associated roles.
During normal business operation, it’s typical for new users to require access to process requests or for the configuration of positions to change. These changes require updates to the underlying data that controls which users have access to requests and their associated roles.
The process of updating request security has historically been the source of performance challenges on larger MDM implementations due to the fact that multiple user actions have a higher chance of causing conflicts.
In the Stewardship Tier 7.4.2 release, Syniti made some architectural changes related to the main stored procedure (webRequest_SecurityIns) which updates how the user security requests run.
Previously, common actions such as those defined below would result in the Stewardship Tier running an event in the foreground for each item.
- User assignment to roles that have MDM positions assigned
- User removal from roles that have MDM positions assigned
- Addition of MDM positions to roles that have users assigned
- Removal of MDM positions from roles that have users assigned
- Deletion of roles that have MDM positions assigned
- Position configuration changes (addition/removal of org units, roles or business processes)
In the 7.4.2 release, the events described above result in background jobs being created in the Stewardship Tier job queue. The created jobs pass in specific parameters to ensure, where possible, that request security rebuilding only occurs on records associated with the specific changes that have been made. The levels at which the request security procedures are run are as follows:
- Execute request security procedure without parameters
- Job name ‘MDMSec Security Full’
- Execute request security procedure by user
- Job name ‘MDMSec <User>’
- Execute request security procedure by Role
- Job name ‘MDMSec <Role>’
- Execute request security procedure by Business Process
- Job name ‘MDMSec <Business Process>’
In order to optimize the processing of request security updates, two security job control parameters have been added to the Master Data Management application:
- Security Job Queue
- Security Job Threads
Security Job Queue—controls which queue the MDM Request Security jobs are processed by. By default, the ‘Security Job Queue’ is set to ‘General;' however, since other jobs run on this queue, we recommend that customers monitor the queue traffic and time taken for security updates to run to ensure the updates are not queued for too long. If there are delays, customers can create a dedicated queue with a higher priority than other queues.
Security Job Threads—controls the number of allowable parallel running security update requests. We recommend that you use the default value of 2, but you can increase this value if there is often a backlog of entries that takes a significant amount of time to run. Increasing this value too much could result in deadlock, so any increases should be carefully monitored.
Additionally, to further optimize the job execution process, logic has been added that prevents new MDM Request Security jobs from being added to the job queue if there is already a job in the queue that would result in the same outcome.
For example, if there is a job in the queue that would rebuild MDM Request Security for position ‘Sales Manager,' if another change was made that would require a rebuild of MDM Request Security for the same position, then no new job would be added to the job queue.
In the case that there is a job in the queue that would do a full request security rebuild that is waiting to run (name MDMSec Security Full), then no new MDM Request Security jobs would be added. If there is currently a full request security rebuild running (name MDMSec Security Full), then newly added MDM Request Security jobs will be added to the queue, but they will run single-threaded behind the running full request security rebuild job.