In this blog, I will explain the use of the retrofit parameter NO_CSOL – No Cross System Object Lock for Import Objects and an unexpected scenario that might not be anticipated.
To demonstrate the use of the parameter I will work with a dual development scenario (N+1 Scenario) with multi-client project landscapes in two systems. The project below shows the two development systems, RIG:501 and SBX:801.
To begin the example the parameter NO_CSOL will be set to inactive.
To demonstrate the retrofit functionality with the parameter inactive, a new program will be created in the development system of the N landscape. To simplify the testing process, the transports will be created and released directly from the project task list. The retrofit activity will be started from the task list as well. The behavior of the retrofit funtionality will be the same as if the transports were created and released through the processing of ChaRM documents.
Program Z_RETROFIT_TEST_1A was created in the development client of the N landscape and saved to a transport.
When the transport is released, the retrofit analysis is performed to determine if the retrofit activity for the transport can be performed automatically or whether a potential conflict exists. The analysis is dependent upon the Cross System Object Lock functionality being activated in the N+1 project landscape. At the time the transport is released from the development system in the N landscape, a check is made against the CSOL entries for the N+1 landscape to determine if any object in the N landscape transport is the focus of a lock entry from the N+1 landscape. If no lock entries exist in the N+1 landscape for any of the objects in the N development transport, the retrofit activity is identified as an “Auto-Import” (green light on the Critical Retrofit column).
Since the object of this example is being created in the N landscape and an object of the same name does not exist in the N+1 landscape, an “Auto-Import” should be expected. This is in fact the case.
To execute the retrofit activities, a target transport is entered in the Retrofit Request column. The entry in the Retrofit list is selected and the retrofit activity is initiated by selecting the Auto-Import button (the Retrofit for All Categories button can also be used).
When the retrofit activity was determined to be an auto-import, the content of the released transport is placed in a transport of copies and placed in the import buffer of the N+1 development system. When the retrofit activity is started, the transport of copies is imported into the N+1 development system and the contents of the transport are placed in the target transport that was entered in the Retrofit Request field.
When the retrofitted object is saved to the target transport, a CSOL warning is generated since CSOL is also turned on for the N landscape.
A pop-up will appear when the retrofit is complete.
Returning to the retrofit listing, the entry turns green and the status is updated to Retrofitted indicating the retrofit is complete and successful.
A review of the target transport shows the following:
It is important to note here that an Auto-Import retrofit should be processed in a timely manner after the N landscape original transport is released. The analysis that is made to determine the Auto-Import retrofit is a point in time analysis. If a change is made in the N+1 development system to one of the objects on an Auto-Import retrofit transport before the retrofit processing occurs, the analysis that made the Auto-Import determination is invalidated. A re-check of the analysis is performed to ensure a downgrade does not occur. This recheck is driven by a Retrofit Parameter NO_RCHK. This parameter is delivered in an Inactive status. When the parameter is activated, the re-check is turned off.
Proceeding with the Auto-Import after the re-check has identified a conflict will likely result in a downgrade for the object that contains the conflict in the N+1 landscape.
There is an option to recalculate the retrofit after the re-check has identified that a change was made after the initial retrofit calculation.
Back to the NO_CSOL demo. The scenario proceeds with a change made to the program RETRO_TEST_1A in the N landscape.
A review of the CSOL lock table after the change is released, shows three entries in the lock table. There is an entry for the transport when the program was initially created, an entry for the change that was made, and an entry due to the report being saved in the transport in the development system of the N+1 as a result of the retrofit.
As a result, the retrofit analysis determines that there is a potential conflict between the N and N+1 versions.
So – even though there was no version discrepancy after the first retrofit activity, the second change in the N landscape is NOT an auto-import due to the fact that the first retrofit activity generated a CSOL entry. When the second change was made and released, the CSOL entry in the table for the N+1 landscape caused the retrofit analysis to determine that a change was made in the N+1 landscape and therefore an analysis is required to determine how the second change should be retrofitted into the N+1 landscape.
In order to avoid this situation, the parameter NO_CSOL can be activated. To demonstrate how this works, the example will be repeated with the parameter activated.
A new report, Z_RETRO_TEST_2A, is created in the N development system.
The task and transport are released in the N development system.
As expected, the retrofit determination indicates an Auto-Import.
A target transport is entered and the retrofit activity is started by selecting the Auto-Import button.
Note that there was no pop-up warning that a CSOL entry exists in the N landscape. Also note that the report is assigned to the target transport at the transport level and not at the task level.
Finally, note the lock status on the object in the transport.
As expected, a check of the CSOL lock table shows no entry for the change in the N+1 landscape.
For the second part of the test, a change will be made to Z_RETRO_TEST_2A in the N development system and retrofitted. When the change is released, the retrofit analysis determines an Auto-Import since there was no CSOL lock generated in the N+1 landscape when the report was retrofitted to the N+1 development system.
After the Auto-Import was executed for the change to the report, the CSOL table shows two entries, one for the original creation of the report and one for the change.
In the N+1 development system, the report is aligned at the transport level and not at the task level.
This results in an interesting situation in which two transports are holding the same object.
As indicated above, this occurs because of the status of the work bench lock being “Object Imported”. This does not provide an exclusive lock.
As a result, a change can also be made to the object in the N+1 development system and recorded to a third transport.
The lock status on the third transport however, indicates an exclusive lock.
If an attempt is made to release one of the retrofit target transports, the release will fail because the transport cannot obtain an exclusive lock during the release process.
In this particular scenario, transport SBXK900340 needs to be released first since it is holding the exclusive lock. When this transport is released, the retrofit target transports can be released because an exclusive lock can then be obtained. Even though each transport will release the same version of the object (assuming no additional changes made to the retrofit transports after the N+1 change is released), the sequence of the release can cause needless confusion and disruption since the source of the failed release has to be researched and resolved.
SAP Note 2384148 - Enhancement of retrofit request object assignment regarding object lock, has been created to address the locking issue identified above. Consult this note to determine if the it is applicable to your system
There are two points that need to be considered when processing retrofits identified as Auto-Imports.
Point 1: Auto-Import retrofits are ensuring the same version of objects in the transport exist in both the N and the N+1 landscape. The NO_CSOL parameter will ensure that multiple changes originating in the N development system will result in Auto-Import retrofits as long as no change is occurring in the N+1 landscape independent of the N landscape changes. However, the above example demonstrates a potential issue resulting from the use of the parameter. To avoid the scenario with multiple transports holding the same object, Auto-Import target transports should be processed in the N+1 landscape to the point of releasing the target transport as quickly as possible. This will minimize the likelihood of encountering a transport that can’t be released due to exclusive lock issues. As noted, SAP Note 2384148 can be applied to address the locking issue
Point 2: The retrofit processing option is determined when the transport in the N landscape is released. As pointed out above, if a change is made in the N+1 landscape to one of the objects on an “Auto-Import” transport before the retrofit is processed, the designation of Auto-Import is no longer valid. When the Auto-Import is subsequently started, a pop-up will occur indicating the analysis is no longer valid. As a result, the retrofit will have to be re-calculated or processed manually. Auto-Import retrofits should be processed in a timely manner after the transport is released in the N landscape so the retrofit analysis will not be nullified by a subsequent change in the N+1 landscape to one of the objects on the transport. This will simplify the overall retrofit process by avoiding the re-calculation of the retrofit content and conflict resolution.
To demonstrate the use of the parameter I will work with a dual development scenario (N+1 Scenario) with multi-client project landscapes in two systems. The project below shows the two development systems, RIG:501 and SBX:801.
To begin the example the parameter NO_CSOL will be set to inactive.
To demonstrate the retrofit functionality with the parameter inactive, a new program will be created in the development system of the N landscape. To simplify the testing process, the transports will be created and released directly from the project task list. The retrofit activity will be started from the task list as well. The behavior of the retrofit funtionality will be the same as if the transports were created and released through the processing of ChaRM documents.
Program Z_RETROFIT_TEST_1A was created in the development client of the N landscape and saved to a transport.
When the transport is released, the retrofit analysis is performed to determine if the retrofit activity for the transport can be performed automatically or whether a potential conflict exists. The analysis is dependent upon the Cross System Object Lock functionality being activated in the N+1 project landscape. At the time the transport is released from the development system in the N landscape, a check is made against the CSOL entries for the N+1 landscape to determine if any object in the N landscape transport is the focus of a lock entry from the N+1 landscape. If no lock entries exist in the N+1 landscape for any of the objects in the N development transport, the retrofit activity is identified as an “Auto-Import” (green light on the Critical Retrofit column).
Since the object of this example is being created in the N landscape and an object of the same name does not exist in the N+1 landscape, an “Auto-Import” should be expected. This is in fact the case.
To execute the retrofit activities, a target transport is entered in the Retrofit Request column. The entry in the Retrofit list is selected and the retrofit activity is initiated by selecting the Auto-Import button (the Retrofit for All Categories button can also be used).
When the retrofit activity was determined to be an auto-import, the content of the released transport is placed in a transport of copies and placed in the import buffer of the N+1 development system. When the retrofit activity is started, the transport of copies is imported into the N+1 development system and the contents of the transport are placed in the target transport that was entered in the Retrofit Request field.
When the retrofitted object is saved to the target transport, a CSOL warning is generated since CSOL is also turned on for the N landscape.
A pop-up will appear when the retrofit is complete.
Returning to the retrofit listing, the entry turns green and the status is updated to Retrofitted indicating the retrofit is complete and successful.
A review of the target transport shows the following:
It is important to note here that an Auto-Import retrofit should be processed in a timely manner after the N landscape original transport is released. The analysis that is made to determine the Auto-Import retrofit is a point in time analysis. If a change is made in the N+1 development system to one of the objects on an Auto-Import retrofit transport before the retrofit processing occurs, the analysis that made the Auto-Import determination is invalidated. A re-check of the analysis is performed to ensure a downgrade does not occur. This recheck is driven by a Retrofit Parameter NO_RCHK. This parameter is delivered in an Inactive status. When the parameter is activated, the re-check is turned off.
Proceeding with the Auto-Import after the re-check has identified a conflict will likely result in a downgrade for the object that contains the conflict in the N+1 landscape.
There is an option to recalculate the retrofit after the re-check has identified that a change was made after the initial retrofit calculation.
Back to the NO_CSOL demo. The scenario proceeds with a change made to the program RETRO_TEST_1A in the N landscape.
A review of the CSOL lock table after the change is released, shows three entries in the lock table. There is an entry for the transport when the program was initially created, an entry for the change that was made, and an entry due to the report being saved in the transport in the development system of the N+1 as a result of the retrofit.
As a result, the retrofit analysis determines that there is a potential conflict between the N and N+1 versions.
So – even though there was no version discrepancy after the first retrofit activity, the second change in the N landscape is NOT an auto-import due to the fact that the first retrofit activity generated a CSOL entry. When the second change was made and released, the CSOL entry in the table for the N+1 landscape caused the retrofit analysis to determine that a change was made in the N+1 landscape and therefore an analysis is required to determine how the second change should be retrofitted into the N+1 landscape.
In order to avoid this situation, the parameter NO_CSOL can be activated. To demonstrate how this works, the example will be repeated with the parameter activated.
A new report, Z_RETRO_TEST_2A, is created in the N development system.
The task and transport are released in the N development system.
As expected, the retrofit determination indicates an Auto-Import.
A target transport is entered and the retrofit activity is started by selecting the Auto-Import button.
Note that there was no pop-up warning that a CSOL entry exists in the N landscape. Also note that the report is assigned to the target transport at the transport level and not at the task level.
Finally, note the lock status on the object in the transport.
As expected, a check of the CSOL lock table shows no entry for the change in the N+1 landscape.
For the second part of the test, a change will be made to Z_RETRO_TEST_2A in the N development system and retrofitted. When the change is released, the retrofit analysis determines an Auto-Import since there was no CSOL lock generated in the N+1 landscape when the report was retrofitted to the N+1 development system.
After the Auto-Import was executed for the change to the report, the CSOL table shows two entries, one for the original creation of the report and one for the change.
In the N+1 development system, the report is aligned at the transport level and not at the task level.
This results in an interesting situation in which two transports are holding the same object.
As indicated above, this occurs because of the status of the work bench lock being “Object Imported”. This does not provide an exclusive lock.
As a result, a change can also be made to the object in the N+1 development system and recorded to a third transport.
The lock status on the third transport however, indicates an exclusive lock.
If an attempt is made to release one of the retrofit target transports, the release will fail because the transport cannot obtain an exclusive lock during the release process.
In this particular scenario, transport SBXK900340 needs to be released first since it is holding the exclusive lock. When this transport is released, the retrofit target transports can be released because an exclusive lock can then be obtained. Even though each transport will release the same version of the object (assuming no additional changes made to the retrofit transports after the N+1 change is released), the sequence of the release can cause needless confusion and disruption since the source of the failed release has to be researched and resolved.
SAP Note 2384148 - Enhancement of retrofit request object assignment regarding object lock, has been created to address the locking issue identified above. Consult this note to determine if the it is applicable to your system
There are two points that need to be considered when processing retrofits identified as Auto-Imports.
Point 1: Auto-Import retrofits are ensuring the same version of objects in the transport exist in both the N and the N+1 landscape. The NO_CSOL parameter will ensure that multiple changes originating in the N development system will result in Auto-Import retrofits as long as no change is occurring in the N+1 landscape independent of the N landscape changes. However, the above example demonstrates a potential issue resulting from the use of the parameter. To avoid the scenario with multiple transports holding the same object, Auto-Import target transports should be processed in the N+1 landscape to the point of releasing the target transport as quickly as possible. This will minimize the likelihood of encountering a transport that can’t be released due to exclusive lock issues. As noted, SAP Note 2384148 can be applied to address the locking issue
Point 2: The retrofit processing option is determined when the transport in the N landscape is released. As pointed out above, if a change is made in the N+1 landscape to one of the objects on an “Auto-Import” transport before the retrofit is processed, the designation of Auto-Import is no longer valid. When the Auto-Import is subsequently started, a pop-up will occur indicating the analysis is no longer valid. As a result, the retrofit will have to be re-calculated or processed manually. Auto-Import retrofits should be processed in a timely manner after the transport is released in the N landscape so the retrofit analysis will not be nullified by a subsequent change in the N+1 landscape to one of the objects on the transport. This will simplify the overall retrofit process by avoiding the re-calculation of the retrofit content and conflict resolution.
- SAP Managed Tags:
1 Comment
