- SAP Managed Tags:
The Focused Build standalone extension 'Cutover Checks and Post Cutover Activities' was introduced a few years ago. In between, it has been enhanced with some new checks. As of Focused Build Support Package 10, there are 5 different checks available:
The main aspect of each of these checks can be found in the Focused Build Configuration Guide. This guide also mentions two BAdIs which you can implement when you miss a specific check, but it is more theoretical and does not contain detailed information
In this blog, I'll show how to add new checks. I use a concrete example to explain, I explain with a concrete example, but the check itself is not fully implemented:
During the post-cutover activities transports of copies are created in the cutover system. An error occurs during they are released if one of the contained objects belongs to a package (development class) that does not exist there. This check verifies whether all packages of imported objects exist in the cutover system or if they will be imported.
After the check has been executed, I want to get a list of all packages for which objects are included in the pending import and whether they exists or will be imported.
Cutover Checks and Activities are available for change cycles. If you have logged on with the business role /SALM/SM_PRO – Solution Manager ITSM, an additional assignment block is available. The block is hidden if the cycle is assigned to a maintenance branch.
The related maintenance landscape is determined automatically based on the production system. The cutover system is the first system that occurs in both the implementation and the maintenance landscape. The Cutover assignment block contains a graphic of the involved systems.
The checks should be executed before the cutover. Usually, all transports of the current cycle that have been released but not yet imported into the cutover system are considered.
The checks are started all at once by pressing the button "Perform Check" in the WebUI. They are executed via batch jobs as depending on the number of transport and objects it may take a while. The results are stored in several database tables to be displayed later. Each time the check are executed, the previous results are overwritten. Therefore, only the latest results are available.
Each cutover check consist of two BAdI implementation. The first one is responsible for the test execution. The second one ensures that the results of the execution are displayed in the change cycle.
I start with the implementation of the check execution using the IMG node SAP Solution Manager -> Focused Build -> Change Control Management Extensions -> Cutover Management -> BAdI: Cutover Check. The existing implementations of the BAdI Definition /SALM/CHARM_CO_CHECK_EXECUTION are listed here, but the screen can be also used to create a new implementation.
After pressing the button "Create Implementation", follow the displayed instructions to create the enhancement implementation and the BAdI implementation. The result will be an enhancement implementation containing an implementation of BAdI definition /SALM/CHARM_CO_CHECK_EXECUTION.
The next step, you create a filter value. This value is later assigned to the result BAdI and used in the customizing. It has to be a four-digit number, so I used "9001".
Since the checks are executed asynchronously, a database table is required to store the results. It should be client dependent and requires some fields which are collected in structure /SALM/CHARM_CO_CHECK_RES_KEY and can be easily included in any result table. In addition to these lines, I just need to add two more: I use the name of the development class and a status.
After selecting the key fields and setting Technical Settings and the enhancement category (can be enhanced deep), the table can be stored and activated.
Next step is to create the implementation of method /SALM/IF_CM_CO_CHECK_EXECUTION~PERFORM_CUTOVER_CHECK in your implementation class.
I recommend looking at one of the delivered classes starting with "/SALM/CL_IM_CO_CHECK_" to get an example. Parts such as retrieving the transport requests or writing the application log can be reused in the current example.
As mentioned before, I did not implement the check completely. The result of my implementation will always contain the same lines in the result table.
At this point the results are stored in the database, but they should be displayed in the Cutover assignment block. So, you need to implement the second BAdI /SALM/CHARM_CO_CHECK_RESULT .
This can be done in the already existing enhancement implementation Z_CO_CHECK_PACKAGE in transaction se80.
In the next dialog the BAdI Definition /SALM/CHARM_CO_CHECK_RESULT and the existing implementing class can be select. A new unique name is required for the BAdI implementation.
After the implementation has been created, the same filter value must be defined. As I have already mentioned, this value will be used in the customizing too. Afterwards the enhancement implementation is ready to be activated.
Next, a structure is needed to represent a line of the check result. It can contain the same fields as the result table, but this is not required. I'd recommend to restrict the number of fields to the displayed columns and to use the same names.
For the current example I'd like to have five fields: name and client of cutover system, package name and the calculated status and a column for the status description. The field labels of the used data element will be used as table headers, which are displayed in the CRM WebUI. It may be necessary to create new data elements to ensure that a meaningful column header is used. This is not important for the result table created above, but since this structure is used to generate the displayed table I have done this for the status column.
The BAdI /SALM/CHARM_CO_CHECK_RESULT has four methods to be implemented:
This method is called to retrieve the high level result, which is displayed in the check overview list. This overall status is returned in the overall_status field of the changing parameter cs_result. Possible values are 'PASS' or 'STOP', for which the constants /tmwflow/if_trans_check_result=>con_result_status-pass or /tmwflow/if_trans_check_result=>con_result_status-stop can be used.
For my package check I have added one line for each package used , each can have a green, yellow ore red traffic light status . As long as the status of the packages is green (exists) or yellow (will be imported) the check itself is passed. A single red entry will lead to a failure.
This method provides the details of the current cutover check as generic table/structure instantiated in CR_DATA. In most cases, the data from the specific results table is only read and converted row by line.
But this method can also be used to enrich the stored data with additional information such as descriptions of a transport, a message text, or calculated values. For example, I have added a corresponding message text for each status.
This method can be used to manipulate the displayed data like hide fields, change a field type or add a tooltip.
In my example, the type of the status field is converted so that it appears as an icon instead of the simple value.
This method is needed in case you have a link within your displayed check results, for example to another change document. It's not necessary for my example, but you will find some examples in the Focused Build implementation classes /SALM/CL_IM_CO_CHECK_CSOL or /SALM/CL_IM_CO_CHECK_RETROFIT.
Almost done, but the new check is still not visible in the assignment block "Cutover Checks and Activities". Some customizing settings still need to be added. This can be done in the IMG node SAP Solution Manager -> Focused Build -> Change Control Management Extensions -> Cutover Management -> Define Cutover Check Settings. A new entry must be created under the tree node "Define Check Types" with the following values::
After saving the changes select the new row. The new check needs to be assigned to the transaction types of the change cycles, where it should be available. This is done in the sub node "Assign Check to process type". I'll use Phase Cycles (SMIM) and Release cycles (SMRE), but this might differ.
Once the check has been added in Customizing, it is visible in the CRM Web UI and can be executed together with all existing checks. The result is displayed in a separate tab with the same title. The result table contains the five columns corresponding to the field of the created result structure. The description text in the last column corresponds to the icon displayed.
Since my example should only show how a new check can be implemented, I do not need to perform any further tests. In the case of a real implementation, a concrete test scenario would still have to be set up.
The cutover checks are essentially to be seen as a framework. This makes it easy to create one or more new cutover checks to complement them according to your own requirements. The checks delivered with Focused Build are also implemented with this framework. As a result, there are also plenty of examples of individual tasks (determine transports, write application log, change or hide columns).
The decisive factor is that the steps mentioned by me are carried out so that all necessary interfaces are used at the end:
The implementation of the actual execution of the check is probably the most time-consuming part, but this depends on the specific requirement.
- Retrofit Scope
- Retrofit Deployment
- Transport Dependencies
- Development Conflicts
- User Check for Synchronize Deployment
The main aspect of each of these checks can be found in the Focused Build Configuration Guide. This guide also mentions two BAdIs which you can implement when you miss a specific check, but it is more theoretical and does not contain detailed information
In this blog, I'll show how to add new checks. I use a concrete example to explain, I explain with a concrete example, but the check itself is not fully implemented:
During the post-cutover activities transports of copies are created in the cutover system. An error occurs during they are released if one of the contained objects belongs to a package (development class) that does not exist there. This check verifies whether all packages of imported objects exist in the cutover system or if they will be imported.
After the check has been executed, I want to get a list of all packages for which objects are included in the pending import and whether they exists or will be imported.
Some theory first
Cutover Checks and Activities are available for change cycles. If you have logged on with the business role /SALM/SM_PRO – Solution Manager ITSM, an additional assignment block is available. The block is hidden if the cycle is assigned to a maintenance branch.
The related maintenance landscape is determined automatically based on the production system. The cutover system is the first system that occurs in both the implementation and the maintenance landscape. The Cutover assignment block contains a graphic of the involved systems.
The checks should be executed before the cutover. Usually, all transports of the current cycle that have been released but not yet imported into the cutover system are considered.
The checks are started all at once by pressing the button "Perform Check" in the WebUI. They are executed via batch jobs as depending on the number of transport and objects it may take a while. The results are stored in several database tables to be displayed later. Each time the check are executed, the previous results are overwritten. Therefore, only the latest results are available.
Implement BAdI for Cutover Check
Each cutover check consist of two BAdI implementation. The first one is responsible for the test execution. The second one ensures that the results of the execution are displayed in the change cycle.
I start with the implementation of the check execution using the IMG node SAP Solution Manager -> Focused Build -> Change Control Management Extensions -> Cutover Management -> BAdI: Cutover Check. The existing implementations of the BAdI Definition /SALM/CHARM_CO_CHECK_EXECUTION are listed here, but the screen can be also used to create a new implementation.
After pressing the button "Create Implementation", follow the displayed instructions to create the enhancement implementation and the BAdI implementation. The result will be an enhancement implementation containing an implementation of BAdI definition /SALM/CHARM_CO_CHECK_EXECUTION.
The next step, you create a filter value. This value is later assigned to the result BAdI and used in the customizing. It has to be a four-digit number, so I used "9001".
Create a Result Table
Since the checks are executed asynchronously, a database table is required to store the results. It should be client dependent and requires some fields which are collected in structure /SALM/CHARM_CO_CHECK_RES_KEY and can be easily included in any result table. In addition to these lines, I just need to add two more: I use the name of the development class and a status.
After selecting the key fields and setting Technical Settings and the enhancement category (can be enhanced deep), the table can be stored and activated.
Implement Check Execution
Next step is to create the implementation of method /SALM/IF_CM_CO_CHECK_EXECUTION~PERFORM_CUTOVER_CHECK in your implementation class.
I recommend looking at one of the delivered classes starting with "/SALM/CL_IM_CO_CHECK_" to get an example. Parts such as retrieving the transport requests or writing the application log can be reused in the current example.
As mentioned before, I did not implement the check completely. The result of my implementation will always contain the same lines in the result table.
Implement BAdI for Cutover Check Results
At this point the results are stored in the database, but they should be displayed in the Cutover assignment block. So, you need to implement the second BAdI /SALM/CHARM_CO_CHECK_RESULT .
This can be done in the already existing enhancement implementation Z_CO_CHECK_PACKAGE in transaction se80.
In the next dialog the BAdI Definition /SALM/CHARM_CO_CHECK_RESULT and the existing implementing class can be select. A new unique name is required for the BAdI implementation.
After the implementation has been created, the same filter value must be defined. As I have already mentioned, this value will be used in the customizing too. Afterwards the enhancement implementation is ready to be activated.
Create result structure for display
Next, a structure is needed to represent a line of the check result. It can contain the same fields as the result table, but this is not required. I'd recommend to restrict the number of fields to the displayed columns and to use the same names.
For the current example I'd like to have five fields: name and client of cutover system, package name and the calculated status and a column for the status description. The field labels of the used data element will be used as table headers, which are displayed in the CRM WebUI. It may be necessary to create new data elements to ensure that a meaningful column header is used. This is not important for the result table created above, but since this structure is used to generate the displayed table I have done this for the status column.
Implementing BAdI methods
The BAdI /SALM/CHARM_CO_CHECK_RESULT has four methods to be implemented:
- GET_OVERALL_RESULT to return the overall check result
- GET_RESULT_DETAILS returns list of check result details
- GET_P_T_RESULT to adjust field properties in UI display
- GET_NAVIGATION_DESCRIPTOR returns a descriptor for dynamic navigation
Method GET_OVERALL_RESULT
This method is called to retrieve the high level result, which is displayed in the check overview list. This overall status is returned in the overall_status field of the changing parameter cs_result. Possible values are 'PASS' or 'STOP', for which the constants /tmwflow/if_trans_check_result=>con_result_status-pass or /tmwflow/if_trans_check_result=>con_result_status-stop can be used.
For my package check I have added one line for each package used , each can have a green, yellow ore red traffic light status . As long as the status of the packages is green (exists) or yellow (will be imported) the check itself is passed. A single red entry will lead to a failure.
METHOD /salm/if_cm_co_check_result~get_overall_result.
**********************************************************************
* provide the highlevel result for this check
**********************************************************************
INCLUDE: <icon>.
DATA: ls_check_result TYPE /salm/cmcoc_user.
IF iv_sys_name IS INITIAL OR
iv_sys_client IS INITIAL.
SELECT SINGLE * FROM zcocpackage INTO ls_check_result
WHERE check_type EQ iv_check_type
AND cycle EQ iv_cycle
AND change_document EQ iv_change_guid
AND status EQ icon_red_light.
ELSE.
SELECT SINGLE * FROM zcocpackage INTO ls_check_result
WHERE check_type EQ iv_check_type
AND cycle EQ iv_cycle
AND change_document EQ iv_change_guid
AND sys_name EQ iv_sys_name
AND sys_client EQ iv_sys_client
AND status EQ icon_red_light.
ENDIF.
"if we do have at least one entry, the check is failed and we should check the
"details
IF sy-subrc EQ 0.
cs_result-overall_status = /tmwflow/if_trans_check_result=>con_result_status-stop.
ELSE.
cs_result-overall_status = /tmwflow/if_trans_check_result=>con_result_status-pass.
ENDIF.
ENDMETHOD.
Method GET_RESULT_DETAILS
This method provides the details of the current cutover check as generic table/structure instantiated in CR_DATA. In most cases, the data from the specific results table is only read and converted row by line.
But this method can also be used to enrich the stored data with additional information such as descriptions of a transport, a message text, or calculated values. For example, I have added a corresponding message text for each status.
METHOD /salm/if_cm_co_check_result~get_result_details.
**********************************************************************
* provide the details of the Cutover Check analysis
* the generic table/tructure we whould return is already
* instantiated in CR_DATA
**********************************************************************
DATA: lt_check_result TYPE TABLE OF zcocpackage_ui,
lv_message TYPE string.
FIELD-SYMBOLS:
<ls_result> LIKE LINE OF lt_check_result,
<lt_table> TYPE ANY TABLE,
<ls_line> TYPE any.
IF iv_sys_name IS INITIAL OR
iv_sys_client IS INITIAL.
SELECT * FROM zcocpackage INTO CORRESPONDING FIELDS OF TABLE lt_check_result
WHERE check_type EQ iv_check_type
AND cycle EQ iv_cycle
AND change_document EQ iv_change_guid.
ELSE.
SELECT * FROM zcocpackage INTO CORRESPONDING FIELDS OF TABLE lt_check_result
WHERE check_type EQ iv_check_type
AND cycle EQ iv_cycle
AND change_document EQ iv_change_guid
AND sys_name EQ iv_sys_name
AND sys_client EQ iv_sys_client.
ENDIF.
ASSIGN cr_data->* TO <lt_table>.
ASSERT sy-subrc EQ 0.
"move details into generic result table
LOOP AT lt_check_result ASSIGNING <ls_result>.
CASE <ls_result>-status.
WHEN icon_red_light.
<ls_result>-message = 'package does not exist in cutover system'(001).
WHEN icon_yellow_light.
<ls_result>-message = 'package does not exist, but will be imported'(002).
WHEN icon_green_light.
<ls_result>-message = 'package exists'(003).
ENDCASE.
"move to result table structure
INSERT INITIAL LINE INTO TABLE <lt_table> ASSIGNING <ls_line>.
MOVE-CORRESPONDING <ls_result> TO <ls_line>.
ENDLOOP.
ENDMETHOD.Method GET_P_T_RESULT
This method can be used to manipulate the displayed data like hide fields, change a field type or add a tooltip.
In my example, the type of the status field is converted so that it appears as an icon instead of the simple value.
METHOD /salm/if_cm_co_check_result~get_p_t_result.
INCLUDE: <icon>.
CASE iv_component.
WHEN 'STATUS'. "#EC NOTEXT
CASE iv_property.
WHEN if_bsp_wd_model_setter_getter=>fp_fieldtype.
cv_value = cl_bsp_dlc_view_descriptor=>field_type_image.
ENDCASE.
ENDCASE.
ENDMETHOD.Method GET_NAVIGATION_DESCRIPTOR
This method is needed in case you have a link within your displayed check results, for example to another change document. It's not necessary for my example, but you will find some examples in the Focused Build implementation classes /SALM/CL_IM_CO_CHECK_CSOL or /SALM/CL_IM_CO_CHECK_RETROFIT.
Define new check in customizing
Almost done, but the new check is still not visible in the assignment block "Cutover Checks and Activities". Some customizing settings still need to be added. This can be done in the IMG node SAP Solution Manager -> Focused Build -> Change Control Management Extensions -> Cutover Management -> Define Cutover Check Settings. A new entry must be created under the tree node "Define Check Types" with the following values::
- Check Type: This is the filter value, I have defined during the BAdI implementation
- Description: This text will be displayed in the UI
- Table Name: The display structure can be selected via F4 Help. It will define the displayed columns
After saving the changes select the new row. The new check needs to be assigned to the transaction types of the change cycles, where it should be available. This is done in the sub node "Assign Check to process type". I'll use Phase Cycles (SMIM) and Release cycles (SMRE), but this might differ.
Everything is done …. Testing!
Once the check has been added in Customizing, it is visible in the CRM Web UI and can be executed together with all existing checks. The result is displayed in a separate tab with the same title. The result table contains the five columns corresponding to the field of the created result structure. The description text in the last column corresponds to the icon displayed.
Since my example should only show how a new check can be implemented, I do not need to perform any further tests. In the case of a real implementation, a concrete test scenario would still have to be set up.
Summary
The cutover checks are essentially to be seen as a framework. This makes it easy to create one or more new cutover checks to complement them according to your own requirements. The checks delivered with Focused Build are also implemented with this framework. As a result, there are also plenty of examples of individual tasks (determine transports, write application log, change or hide columns).
The decisive factor is that the steps mentioned by me are carried out so that all necessary interfaces are used at the end:
- Implementation of the Check BAdI () and creation of the results table
- Implementation of the Result BAdI () and creation of the UI structure
- Customizing of the new check in accordance with the defined filter value
The implementation of the actual execution of the check is probably the most time-consuming part, but this depends on the specific requirement.
