SAP Solution Manager 7.2 Process Management – Displaying Assigned Change Documents
SAP Solution Manager 7.2. SP05 introduced a new “Related Documents” section in the Process Management application. This new section displays the type and number of “loosely coupled” documents assigned to the current element. These documents could be Incidents, or Requests for Change, or similar.
SAP delivers several pre-configured document types, some active and some inactive. By default Incidents and Requests for Change are active. You can activate the other document types, such as Issues or Functional Gaps, by activating BAdI (Business Add-In) implementations – there is an activity in SAP Solution Manager Setup for doing this.
We also realize that you might want to add additional documents types to the Related Documents section. We have had several requests to display Change Documents here as well. To do so only takes a few steps, which I will describe below.
The related documents section:
Summary of What You Will Have to Do
You will need to do the following:
- Copy the class used in the BAdI implementation
- Make a small adjustment to the code in the class constructor.
- Activate the code.
- Copy the corresponding BAdI implementation.
- Adjust the BAdI implementation.
- Adjust the BAdI’s filter.
- Activate the BAdI implementation.
I’ve described each step in detail in the following sections, using the example of Change Documents. To make things easy, we will copy the BAdI implementation for Requests for Changes and adapt it for Change Documents.
Copy the Class for the BAdI Implementation
- Call transaction SE24 (Class Builder).
- Enter “CL_AGS_CRM_API_SMUD_LCO_RFC” as the object type.
- Select Copy Class/Interface
- Enter ZZCL_AGS_CRM_API_SMUD_LCO_CD or another suitable name for the copied class.
- Enter package information (or select local if you do not want to transport the new class).
How to copy class CL_AGS_CRM_API_SMUD_LCO_RFC in transaction SE24:
Adjust the Class Constructor
- While still in SE24, select Change for the copied class.
- Double-click method CONSTRUCTOR in order to edit the code.
- Change both instances of ‘cl_ags_crm_smud_util=>cs_sbom_type-cr‘ to ‘cl_ags_crm_smud_util=>cs_sbom_type-dos‘.
- Change ‘Requests for Change'(rfc) to ‘Change Documents'(cds). (For bonus points, finish creating this as a translatable text and provide translations.)
- Change ‘AIC_OB_CMCR’ to ‘AIC_OB_CMCD’
This is whatthe adjusted code should look like:
Here are brief descriptions of the attributes which you changed:
- SBOM type: the technical ID of the document type which the system stores in database table SMUD_SBOM_H. Take a look at the table in your system for examples. Change Documents use the ID “DOS”, as I provided in the example, as well as “CD”.
- Loosely coupled type: generally the same as the SBOM type, however there are some special cases where these types differ. For example, Functional Gaps (which are really a type of Incident) have SBOM ID = “INC” but loosely coupled type “ICCGAP”. The system uses the loosely coupled type to separate Functional Gaps from Incidents, although both are saved in table SMUD_SBOM_H with type “INC”. You can freely define the loosely coupled type, as long as it does not conflict with a type defined for another active BAdI implementation.
- SBOM text: this is the text which the system displays in the Related Documents section for the document type.
- CRM UI object type: if the document is a CRM process type, the system uses this attribute to construct the URL for navigation to the document. You can find the CRM UI object type by navigating to a document in the CRM UI, selecting a field, and pressing the F2 key.
Activate the Code
- While still in the constructor method, select the Activate icon.
- Select all objects in the following dialog box.
Make sure you select ALL objects when you activate:
Copy the BAdI Implementation
- Call transaction SE19 (BAdI Builder).
- Enter AGS_CRM_API_LCO_RFC in the field “New BAdI Enhancement Implementation”.
- Select Copy implementation
- Enter a new name for the copied BAdI implementation, for example ‘ZZ_AGS_CRM_API_LCO_CD’.
- Enter package information (or select local if you do not want to transport the new class).
How to copy the BAdI implementation:
Adjust the BAdI Implementation
Note: after you copy the BAdI implementation, the system does not automatically enter the name of the copied BAdI implementation. Do not forget this!
- Enter the name of the newly copied BAdI implementation in the Enhancement Implementation field.
- Select Change.
- Delete the existing BAdI implementations
- Select ‘Create BAdI Implementation’.
- Enter the following information in the dialog box (see screenshot below):
- BAdI Definition: BADI_SMUDE_LCO_INTEGRATION
- BAdI Implementation: ZZ_AGS_CRM_API_LCO_CD (or your own suitable name).
- Implementing class: the name of the class you copied above, for example ZZCL_AGS_CRM_API_SMUD_LCO_CD.
- A descriptive short text. (The system will not display this text in your users’ UIs.)
- Select continue to create the new implementation.
Add a Filter for the BAdI
- Navigate to the Filter section of the implementation
- Create a new filter combination (see first screenshot below):
- Enter ‘DOS’ as Value 1.
- Select Continue.
- Add a new OR combination.
- Enter ‘*’ as Value 1
- Select Continue.
Creating the first filter combination:
This is how the final filter should look like:
Activate the BAdI Implementation
Select the Activate icon. You should be finished now.
The final enhancement implementation should look like this:
If you have managed to follow my instructions, the system will now add a “Change Documents” label to the Related Documents section:
Update: How to Display CRM Knowledge Articles
Update June 3, 2019: we have received several inquiries about CRM Knowledge Articles. Although this was not a planned use case, you can still use the instructions above to display and assign Knowledge Articles to the Related Documents section.
Since this was not a planned use case of this function, you should be aware of the following before getting started:
- This is consulting information. SAP can only provide limited support if you require assistance.
- We don’t cover adding a Solution Documentation assignment block to the CRM Knowledge Articles UI. This would be another, perhaps difficult, project.
- You can still assign Knowledge Articles to the Related Documents section, but you have to do that using the simple application you launch when you select the corresponding “assigned” link next to the document type in the Related Documents assignment block.
To display CRM Knowledge Articles, follow the same instructions for displaying Change Documents with the following exceptions:
- Add the following code to the CONSTRUCTOR method
mo_sbom_type = 'KNAR'. mo_sbom_lco_type = 'KNAR'. mo_sbom_text = 'Knowledge Articles'(knr). mo_crm_ui_object_type = 'BT106_KA'.
- Use ‘KNAR’ instead of ‘DOS’ in the BAdI filter.
- Make an entry in Transaction DNO_CUST04:
Field Name: SMUD_TYPE_KNAR Field Value = KNAR (or ZNAR, or similar if you use a different transaction type)
- Make an entry in view BSPDLCVC_OBJ_TYP:
Object Type: BT106_KA Description: Knowledge Articles Callback Class: CL_CRM_UIU_BT_OBJTYPE_CALLBACK GenIL Component Name: BT BOL Object Name: BTOrder BOR Object Type: BUS2000106 Extensible BO: (leave blank)
Good blog. Can the items/objects listed under "Test Management" also be included under "Related Documents"? If not, what are the options for displaying all related documents and objects in one report?
Thanks in advance for your time and help.
With SP06, Process Management rolled out an integrated reporting function, in which you can see Related Documents together. There should be more information if you check the Process Management material for ST720 SP06.
CRM transactions, such as Defect Corrections, should appear under Incidents in the Related Documents section. If you wanted to display Defect Corrections separately, you'd have to create your own BAdI implementation similar to what I have described in the blog. Displaying anything else from the Test Suite, such as Test Cases could theoretically be done with the BAdI implementations, but it would be a lot of development work.
Take a look at the new reporting. Perhaps this will be enough for your purposes.
Thank you for your valuable explanations.
I have integrated “Issues” section under “Related Objects” by following your instructions.
But I have a question regarding to “Issue” reporting which were associated with Solution Documentation. Our project team having trouble with reporting Solution-based “Issues” .
A reporting option already exist but list layout does not include any field from “Solution Documentation” although we are able to connect these objects by using context definitions.
Is it possible to have “Solution/Branch” field or fields included in available field list?
You stated that “With SP06, Process Management rolled out an integrated reporting function, in which you can see Related Documents together.” Could new functionalities provided by SP06 be an answer to our requirements? Because we running SP05.
Thank you Gordon for this very useful information. I implemented the BADI and solved a request from my customer.
All the best,
Is it possible to keep closed RfCs coupled to Related Documents section in SolDoc?
Currently the link decouples once the related document has reached an workflow end point (Rejected, Confirmed, Completed, …)
It is still possible to re-link closed documents by using the "Assing existing Object". Also in ChaRM Web UI, under Solution Documentation Assigment Block, the link remains coupled after the Transaction (e.g. ZMCR) has been closed.
Is there a setting to display closed documents in SolDoc too? If not, is it possible to implement such a feature?
Thanks for your support!
thanks for this very helpful Blog. We are using Focused Build in parallel with Enhanced ChaRM functionalities.
This created sort of a headache as Focused Build is using a different Frontend than CRM UI and jumps to UI5 Application instead of CRM_UI. All fine with this, but the WebDynpro AGS_CRM_EXT_SMUD_OBJECTS does not handle the BADI implementations correct in SP10 (and most probably before SP10).
the “COMPONENTCONTROLER” Method “GET_ASSIGNED_OBJECTS” uses a simple READ .. INDEX 1… to find the BADI Implementation, not differentiating a lot.
This leads to “unfiltered” Results combining Focused Build WorkItems S1CG / S1MJ and ZMMJ, ZMHF etc.
I was able to solve the Issue only by enhancing the WebDynpro “COMPONENTCONTROLER” Mehtod “GET_ASSIGNED_OBJECTS” due to the fact that the BADI Implementation for Focused Build in the Class “/SALM/CL_SMUDE_LCO_EXT_WI” is not implementing the Interface “IF_AGS_CRM_SMUD_INTEGRATION” with a LOOP instead of the READ statement.
Probably this can be handled better in the standard WebDynpro?
Does this implementation allows us to only assign change documents or can be used to also create new change document if we create a CD from SOLDOC?
I would like to delimit the creation of "Change Documents" only to "Normal Changes = ZMMJ", no other change documents.
Is there a simple possibility to change it via the customizing.
Authorizations are not a possibility, as we are using other Change types for Bug Fixings which are authorized to be created for the same users.
Appreciate your help