Strategy Considerations for Enhanced Retrofit

Many customers using ChaRM and Enhanced Retrofit in an N+1 scenario often have strategy questions such as:

How frequently should retrofit be performed?

Who should perform the retrofit?

Should a single target retrofit transport be used or does each transport that is retrofitted need a separate target transport?

Do “Auto-Import” objects have to be re-imported into the production system?

There are no simple answers to these type of questions and the reality is that the customer has to define a retrofit process that not only satisfies any technical requirements dictated by the tool itself, but also any corporate requirements that might impact their process. The only way to determine what the process should be is to understand the tool and apply the technical and processing details of the tool in conjunction with any corporate requirements.

To that end – this blog is intended to provide details as to how Enhanced Retrofit works and how to incorporate this knowledge into practical ER process options that can then be evaluated against specific corporate requirements. This blog will primarily address the “Auto-Import” retrofit scenario.

The purpose of an N+1 landscape is to allow parallel development in two separate systems. This allows major development to occur in a project development system while maintenance and production support occurs in a maintenance development system.  The challenge is to ensure that the project development system is always aligned with maintenance changes that are approved, and will ultimately move to production, prior to the project development being deployed to production.

Enhanced Retrofit is based on Cross System Object Locking entries having been captured in the project development system. Activating CSOL for the project development system is a requirement.  Any change to a repository object or a configuration object is captured as soon as the entry is save for the first time.  This lock table is queried when a transport is released in the maintenance landscape.  A check is made for each object on the maintenance transport to determine if a change has also been made for that object in the project development system.  If a change is detected and the ER tool set can assist with the resolution of the potential conflict (Software Change Work Bench for eligible repository objects and BC Sets for configuration objects) the retrofit evaluation results in a conflict scenario (yellow traffic light in the retrofit listing).  If a change is detected and the ER tool set cannot assist in the resolution of the conflict (i.e. help objects), then the retrofit evaluation results in a manual scenario meaning the user will have to manually evaluate the objects in both systems to determine the path forward for the project.  If no change is detected in the project development system, the retrofit evaluation determines that the object can be simply imported into the project development system in order to maintain the same version of the object in both systems and landscapes.  These objects are determined to be of the type “Auto-Import” and are marked with a green traffic light indicator.

For processing considerations, let’s put the retrofit scenarios in two separate groups: “Auto-Import Retrofits” and “Conflict Retrofits”.  This blog will primarily address the “Auto-Import” scenarios.

The “Auto-Import Retrofits” are the easiest to process, but perhaps the most difficult for which to develop a strategy. When the “Auto-Import” option is determined for an object, the object is placed in a Transport of Copies that is ultimately released and placed in the import buffer of the project development system awaiting the ER processing.  When the list is processed, a target transport is identified in the ER listing and the “Auto-Import” processing is initiated.  The TOC is imported into the project development system and the contents of the TOC are then added to the target transport for processing in the project landscape.

Processing of “Auto-Import” objects can be done by anyone with the proper authorizations since there is really no knowledge of the objects themselves required to process the “Auto-Import”. As long as the target transport is identified, there is no need to know the exact nature of the objects themselves.  Obviously, if the process fails for some reason – Basis assistance would be perhaps necessary, and maybe development or configuration expertise as well.  However, in general, the expertise is not necessary to process “Auto-Import” retrofits.  In the case of the “Conflict Retrofits”, specific expertise is required to identify and resolve any conflicts that exist between the two landscapes.  A process will need to be defined which assigns the initial processing to a specific group of people, however, collaboration between the support and the project teams may be necessary to resolve any conflict.

The question of when to perform the retrofit activities is subject to several considerations.

The first consideration is the fact that the ER evaluation that is made when the objects are released from the maintenance development system as a point-in-time analysis. If an “Auto-Import” determination is made when the object is released, that means that there has not been a change made to the object in the project landscape up to that point in time.  The validity of the evaluation is good only as long as no change is made in the project landscape.  If a change is made in the project landscape prior to processing an “Auto-Import” retrofit, the system will warn you that a change to one of the objects has occurred and that it is dangerous to continue with the “Auto-Import” processing.  The problem is that the entire contents of the “Auto-Import” transport now have to be processed manually.  The tool does not recalculate the analysis to exclude the changed object.  Because future changes in the project landscape can invalidate the ER analysis, it is prudent to process the “Auto-Import” retrofits as quickly as possible so that no changes will disrupt the automatic processing of the maintenance changes.

The second consideration is the timing of when the objects are released in the maintenance development system and how quickly they will be approved for production and moved to production. The out-of-the box functionality enables the retrofit activity as soon as the transport containing the object is released.    For changes associated with a Normal Change, it could be a requirement that the retrofit activity be performed before the change can migrate to production.  This will eliminate this issue where someone forgot to retrofit the changes after the changes were moved to production.  Urgent Changes may need to be retrofitted after the move to production and as such, the Urgent Change document enables retrofitting from the document in the status of “Imported into Production” and “Confirmed”.  Retrofit processing can always be triggered from the task list and the changes will appear in the retrofit list as soon as the transport is released in the maintenance development system.

One thing that is most unlikely to occur is the move to production and the retrofit processing occurring at the same time. As a result, the process that is ultimately identified will have to include the contingency plan for what happens if a change that has been retrofitted into the project landscape is for some extreme reason, removed from the list of changes approved for production.  So, in the case where the retrofit is performed soon after the release of the changes in the maintenance landscape to avoid issues with subsequent changes in the project landscape, there is always the possibility that a retrofit will have to be reversed if an approved maintenance change is cancelled at the last minute.

Any retrofit process will have to balance the potential for having to reverse a change that has been retrofitted an is no longer approved for production versus the possibility of a change in the project development system invalidating the retrofit analysis and making what was an “Auto-Import” now a manual retrofit. This type of decision can only be made know the habits of the customer, the nature of the project, the volume of maintenance changes, etc.

The options for identifying the target transport in the retrofit process are pretty straight forward. Either a unique target transport is created for each source transport, or the source transports are grouped in a target transport based on some criteria.

The practice to identify a unique target transport for each transport to be retrofitted may seem like a logical approach so there is a one to one relationship between source and target. However, scenarios may very likely exist that a single source transport may have multiple objects that have been changed in the project development system.  In the case of repository objects, workbench locks may exist that connect the objects to different transports in the project development system.  In this case, the retrofit process will have to be manual and the changes retrofitted into the appropriate transports in the project development system.  This scenario can obviously only play out for “Conflict Retrofits”.  However, it brings to light that there are possible retrofit scenarios that are not straight forward in terms of how they are processed and it brings to light the fact that it may not be possible to always create a unique relationship between source and target.

“Auto-Import Retrofits” can always have a single target transport since there are no conflicts to be dealt with.   So – it is possible to create a unique relationship between the source transport and the target transport.  However, it is also possible to create target transports based on a retrofit frequency – perhaps a daily retrofit or weekly retrofit, or a retrofit cycle determined by the maintenance go-live cycle.  All transports that are retrofit candidates during the day, the week or the maintenance cycle are all retrofitted into the appropriate target transport.    What is critical to consider here is the timing of the release of the target transport so that dependencies and/or conflict scenarios are not created when a change is made to one of the objects by the project.  Depending upon the status of the NO_CSOL parameter, there may be changes to repository objects in the target transport that do not hold workbench locks.  (See my blog: NO_CSOL Parameter for Enhanced Retrofit).  If a workbench lock is held – the project change will either have to be manually assigned to the retrofit target transport due to the lock, or the target transport will have to be released to remove the work bench lock so the change can be saved to the appropriate transport for the project.

Since the “Auto-Import Retrofits” are simply synchronizing the project landscape with the same version of objects that are changing in the maintenance landscape, there is more freedom with the timing of the release of the target transports. The target transports can be incorporated in the list of project change documents and transports that need to be processed when the project is moving through the landscape.  However, since the target transports merely contain changes that are already in production (or soon will be), they can be released and moved through the project landscape ahead of the project transports.  Effectively, the target transports are simply “re-setting” the systems to reflect what is in production and does not contain any project related changes.   Regardless of the retrofit frequency (daily, weekly, based on maintenance go-live), the transports can be released as soon as all of the “Auto-Import” retrofits are completed.  This will alleviate any potential workbench lock issues, and will enable downstream systems (QA, Pre-PRD, Testing, etc…) to be synchronized on an on-going basis.

A further consideration for the “Auto-Import Retrofits” relates to whether the changes need to be imported to production again. From a technical standpoint, the answer is “no”.   The changes were imported into production and retrofitted into the project landscape.  Technically, the only systems requiring the changes are the project related systems, development, quality assurance, testing, etc.  From a “Best Practice” standpoint, there may be documents that say that the changes should be imported into production again since the changes are part of the project moving through the project landscape and everything that moves through the landscape should move to production.  Including the changes in the production cutover should be considered based on the facts and requirements of the customer and the project.

Re-importing the transports simplifies the cutover process for the project since anything that is released from the project development system will be ultimately imported into production. There is no need to keep track of the transports in two separate groups.  However, some objects, security changes for example, can take a very long time to import.  If a large number of security objects have been retrofitted to the project landscape, re-importing the objects could have an impact on the import window at cutover.  If the objects are not re-imported, a time savings can be realized for the project.  Not re-importing the transports, however, adds a level of complexity to the project in terms of how to keep track of the transports that should not be re-imported.  If a customer is using ChaRM or QGM to manage transports in the project landscape, a separate project/cycle can be defined for the “Auto-Import” target transports.  In this way – the tool will keep the transports separated based on the CTS project identified with the transports.  The complexity here is that the retrofit process now has two paths – one for the “Auto-Import Retrofits” and one for the “Conflict Retrofits”.  Whoever is processing the retrofits needs to ensure they create the target transports with the correct CTS Project ID association.  If the “Auto-Import Retrofit” target transports will not be moved to production with the project cutover, a two-system project can be defined in ChaRM or QGM where the QA system represents the production target for the “Auto-Import Retrofit target transports.  This will allow the transports to move to the QA system and the associated ChaRM document or QGM change can be closed.  Even though the transports will be delivered to the production buffer, there will not be an import activity available to import the transports into production as long as the transports aren’t imported via STMS.

For customers that are currently using or are considering the use of the ST-OST add-on for Solution Manager, there are ChaRM/Retrofit specific features in the add-on that can help with the “Auto-Import Retrofit” scenario. One feature is a scheduled retrofit job that will process the “Auto-Import Retrofit” entries.  This could easily be used to setup a daily or weekly retrofit cycle for the auto-imports.  This option is available in both the add-on for Solution Manager 7.1 SP13 and Solution Manager 7.2 support pack 3.  Additionally, the Solution Manager 7.2 add-on includes a feature to designate the target transport as a transport of copies.  In this scenario, when the transport is released, the changes will import to the quality assurance system and stop.  If the project landscape is simply a development and quality assurance system, this will synchronize the project landscape without including the transports in the project cutover.  For those customers considering ST-OST for Solution Manager 7.2, be aware that the add-on is not yet available for GA.  An announcement is expected soon as to when the ST-OST add-on will be available for Solution Manager 7.2.