Load verification is an optional cycle in a project using downtime-optimized conversion. The goal is to evaluate the impact of the online activities of the end users on the delta activities.
Load Verification without Downtime
- Run the downtime-optimized conversion on production system until downtime dialog.
- Reset the run before entering the downtime.
- Goal is Load Verification: evaluate impact of online activities by end users ("load").
- Production like load cannot be reproduced in sandbox environment.
The benefits of executing a load verification are as follows:
- Real evaluation of load impact
- Verify that load can be handled by Software Update Manager replication
- Verify that the finance (FIN) customizing request fits to production system status
- Verify that the other transports in the buffer can be imported
- Proof that restrictions on production are followed
- Check that the Asset Accounting activities are aligned and work
- Verify that all prerequisites are met - for example, Simplification Item Check
Executing a load verification bears certain side effects:
- Additional cycle has to be considered during project planning.
- Load verification has to be planned timely near production conversion run as bigger gaps introduce risk of changes on production between load verification and production run.
- Asset Accounting activities (like periodic APC postings, recalculating plan values) will have to be executed twice on production.
- Restrictions of the downtime-optimized conversion uptime processing are active on production (for example, workbench lock, restricted activities).
Load Verification with Downtime
Load verification as described above only covers the uptime phases of the downtime-optimized conversion. To evaluate also the downtime phases to especially get an understanding on the duration of the delta migration and delta data conversion, it is required to clone the production landscape at the time of the downtime dialog. Finishing the run on the isolated clone provides insights into the duration of the downtime phases. This is the concept of delta load verification:
- Run the downtime-optimized conversion on production system until downtime dialog.
- Clone the landscape.
- Reset the run on the real production system before entering the downtime (or stay on downtime dialog, if production downtime is planned soon).
- Example: downtime dialog on Wednesday, then create clone, run Load Verification, verify that PRD downtime can start on Friday.
- Goal is Delta Load Verification: measure the downtime duration of delta replication.
Aspects of Delta Load Verification
- Measure downtime duration for delta migration and conversion.
- Detect potential downtime related errors.
- Option to do a production-like dress rehearsal of downtime activities.
- Approach can be used if a virtualization technique is used and the clone is completely isolated. Only then Software Update Manager will work as is with existing parameters like host names.
- Additional effort may allow checking connection to satellite systems and integration.
- Delta load verification introduces high effort.
- No direct support for cloning by tools like Software Update Manager.