Block synchronization
The Block Synchronization feature of Material Management takes care of synchronizing block creations and deletions in Material Management to Block Management. The data is created automatically whenever a change occurs, and is sent to Block Management in batches with configurable intervals and batch sizes.
Flow
Creation of synchronization data
The BlockSynchronizationTrigger acts as a trigger on the MAT_BLOCKS table. Its purpose is to update the contents of the BlockSync table based on changes occurring in MAT_BLOCKS. Any addition or deletion in MAT_BLOCKS will result in a corresponding modification in the BlockSync table.
Data handling
The BlockSynchronizationTrigger ensures that the BlockSync table remains consistent with the MAT_BLOCKS table.
| Operation | BlockSync Table Behavior |
|---|---|
Add/Create |
When a new block is created in MAT_BLOCKS, an entry with the BlockId and Priority 0 is added to the BlockSync table. |
Update |
Updates to existing blocks in MAT_BLOCKS, like changing the reasonText of a manual block, are not handled by this synchronization trigger. This means that such changes will not be reflected in Block Management. The BlockSync table remains unchanged for update operations on MAT_BLOCKS. |
Delete |
When a block is deleted from MAT_BLOCKS, the following logic applies to the BlockSync table:
|
Mapping of Material Management data to Block Management data
The following mappings describe how Material Management data is transformed into requests for the Block Management API.
Create block
When creating a block in Block Management, the following mapping is used for the PUT /bms-backend/api/v1/{tenantId}/blocks endpoint:
| Block Management Field | Material Management Mapping |
|---|---|
sourcePlant |
The configured source plant |
sourceApplication |
Material Management |
sourceApplicationToken |
The Multitenant Access Control client identifier of Material Management |
sourceBlockIdentifier |
The block identifier |
reason |
The block’s reason text |
blockType |
Material |
blockItems |
The block’s material identifier |
inherited |
False |
severity |
Mapped from the block’s priority |
sourceBlockToken |
The block identifier |
info |
The block’s reason text |
Release block
Deleting material in Material Management triggers the release of a block in Block Management. The following mapping applies to the PUT /bms-backend/api/v1/{tenantId}/blocks/{blockId}/release endpoint:
| Block Management Field | Material Management Mapping |
|---|---|
ROUTE blockId |
The block identifier in Block Management |
sourceApplicationToken |
The Multitenant Access Control client identifier of Material Management |
releaseBlockId |
The block identifier in Block Management |
releasedAt |
The date and time when the delete event happened in Material Management |
isClient |
true |
BODY blockId |
The block identifier in Block Management |
reason |
'Released by Material Management' |
Use cases
Create a block
When a block is created in Material Management, the BlockSynchronizationTrigger adds an entry to the BlockSync table with the BlockId and Priority 0. The BlockSync Job will then process this entry by calling the PUT /bms-backend/api/v1/{tenantId}/blocks endpoint in Block Management to create the corresponding block.
Release a block
When a block is deleted in Material Management, the BlockSynchronizationTrigger updates the BlockSync table based on the existing entry’s status:
-
If an entry for the BlockId exists with Status WAITING or FAILED, the entry is deleted.
-
If the entry’s status is SYNCING, the entry is kept, and a new entry with type DELETE is added.
-
If no entry exists, a new DELETE entry is created.
The BlockSync Job will process these DELETE entries by calling the PUT /bms-backend/api/v1/{tenantId}/blocks/{blockId}/release endpoint in Block Management to release the corresponding block.
Error correction job
To address potential communication faults and ensure data consistency, a daily error correction job is implemented. This job operates on the premise that Material Management’s data flow is correct and any discrepancies should be synchronized towards Material Management, with Block Management acting as the master source for this specific process.
Logic
Prerequisites
-
Data will be checked in batches.
-
Block Management is considered the master source of truth for this synchronization.
-
The data check occurs once every day.
-
The job saves the current progress to allow for continuation in subsequent runs.
Flow
A job fetches blocks from Block Management and cross-references these blocks with corresponding blocks in Material Management. This job will be scheduled daily. If blocks are missing in Material Management that are present in Block Management, the blocks should be created in Material Management. If blocks exist in Material Management but not in Block Management, a block will only be deleted from Material Management if Block Management explicitly shows that the block was released.
The job reschedules itself for upcoming batches until all blocks have been processed. After processing all blocks, the next schedule time should revert to the next day’s original schedule time.