Solman Archives » Musings of an IT Implementor

HowTo: Delete Multiple Workmodes ABAP – Solution Manager 7.1

Scenario: You’ve setup lots of work modes and assigned them to lots of SAP systems and lots of databases.
However, you now would like to remove them all.

Unfortunately the only method provided by SAP to remove workmodes, is very slow as you must manually go through each SAP system and then each database and remove the workmodes. This is very time consuming.

Instead, it’s possible to do this using the ABAP API provided by SAP.
I’ve provided below a sample of the ABAP I have used to remove all workmodes.
I created it to remove all workmodes from all SAP systems and all databases.
Below we make a call to get the workmodes assign to all SAP systems:

DATA lt_entries type DSWPT_DTM_DT_ALLDT_DISPLAY.

CALL FUNCTION ‘FDSWP_GET_DOWNTIMES_UPTIMES’ DESTINATION ‘NONE’
EXPORTING
        IV_DOWNTIMES           = ‘X’
        IV_UPTIMES             = ‘X’
        IV_COMPONENT_KEY       = ‘SID’
        IV_COMPONENT_TYPE      = ‘SMSY’
        IV_IS_DB               = ‘-‘
IMPORTING
        EV_ERROR               = lv_error
        ET_ENTRIES             = lt_entries
.

We then call the function in a loop (looping on lt_entries) to delete the workmode assignment:

DATA ls_guid type DSWPS_DTM_DT_ALLDT_DISPLAY-ENTRY_GUID.

CALL FUNCTION ‘FDSWP_DELETE_WORKMODE_DTM’ DESTINATION ‘NONE’
EXPORTING
IV_WORKMODE_ENTRY_GUID = ls_guid
IMPORTING
EV_DELETED = lv_error.
WRITE: lv_error.

Solman 7.1 LMDB vs SMSY Row Count Mismatch

Scenario: From transaction LMDB in Solman 7.1, you can run variaous validation checks against the LMDB.
One of these validates the number of logical components in the LMDB versus the old SMSY.

When I ran this validation check, there was a slight mismatch, more rows were found in the LMDB compared to the SMSY. But no further information was provided.

So, to be able to work out which logical component was missing, I had to manually compare the table content of table SMSY_SYSTEM and table LMDB_LC_HD.
From this I found the logical component that I needed to remove from SMSY and I then removed it using SMSY.

Solution Manager 7.01 MOPZ Stuck Calculating Selection

I had an issue with Solution Manager 7.01 SP24 where I had created a maintenance transaction for an SEM system (with a sidecar Java stack) and it got stuck in the “calculating” step when in the “Selection” stage.
It would just sit on the screen with the blue circular logo spinning and nothing happening. It did not timeout and when I left it for a day, it was still not progressing.

So, I opened another one, and it got stuck at the same point:

Solution Manager MOPz Calculating Stuck

I had made a change to the Java stack technical system in SMSY to indicate that the landscape pattern was “SIDECAR” as instructed by the SAP documentation, but this just didn’t seem to be working for me.

So I removed the “SIDECAR” definition and now want to cancel the two transactions:

MOPz transactions

Following SAP note 1296589, I opened transaction “/TMWFLOW/MAINTENANCE” and entered in the two “open” transaction IDs and clicked Execute:

/TMFLOW/MAINTENANCE report

The SAP note goes on to say: “If any MOPZ planning procedure is displayed in the search result with User Status other than “New”, then it’s the locking planning procedure.“.
So we can see that we have both transactions locking the planning procedure. Woops!

Maintain the table TSOCM_COND_MAPP using SM30 (use a user other than DDIC for this!):

Table TSOCM_COND_MAPP

Find the line entry “SLMO SLMO0001 E0002 40 SYSTEM_ASSIGNMENT…”:

Change the column “MT” from “Cancel” to “Warning”:

Table TSOCM_COND_MAPP entries for SLMO

Save your change. You will need to save the change to a transport request:

I then re-opened the maintenance transaction from SOLUTION_MANAGER and unfortunately it was still stuck on “Calculating…”.
So, the next step was to try and remove the two transactions.
The SAP notes and SCN both suggested using report CRM_ORDER_DELETE.
From SE38 I ran the report and entered the first transaction ID number (from the maintenance optimizer screen) and “Business Transaction Type” of SLMO:

Deleting SLMO entries

I then went back into the Maintenance Optimizer and click Refresh:

It’s gone! Only one to go:

After removing both old transactions, I went and re-modified the landscape pattern to un-link the Java stack from the ABAP stack (non-SIDECAR).

I then reset the change to the TSOCM_COND_MAPP table and saved it.
I was then able to create a new maintenance transaction and successfully calculate the stack.

Summary:
The SIDECAR landscape pattern in Solution Manager 7.01 SP24 doesn’t seem to work as it should and causes issues with the Maintenance Optimizer. For the time being, it might be easier to try and maintain the ABAP and Java stacks independently.

HowTo: Find Which Version Of Solution Manager You’re Running

Scenario: You want to know which version of Solution Manager you are currently using.
The problem with Solution Manager, is that it has been through the SAP makeover factory a couple of times and been given new names. Not only this, but like other SAP products, the version of Solution Manager may not actually be easily discernable.
SAP note 394616 – “Release strategy for SAP Solution Manager”, provides the answer.
From within your Solution Manager system, select “System -> Status” from the SAP GUI menu, and check for the version of the “ST” component:

In the popup, you will see the general description:
TIP: If you hover the mouse over the text field, you can see the whole string, or you can scroll left and right when the cursor is inside the field.

Component Version

If you click the magnifying glass icon, you can see the full system component list and versions:

You are looking for the component “ST” in the list:

This can be compared to the contents of the SAP note 394616 mentioned earlier.
As the above example shows, ST version 400 patch 24 = SAP Solution Manager 7.0 EHP 1.

SAP Solution Manager 7.1 on HANA=
ST Release ST 712
NW Release NW 7.4

SAP Solution Manager 7.1=
ST Release ST 710
NW Release NW 7.0 EHP 2

SAP Solution Manager 7.0 EHP 1=
ST Release ST 400
NW Release NW 7.0 EHP 1

SAP Solution Manager 7.0=
ST Release ST 400
NW Release NW 7.0

SAP Solution Manager 3.2=
ST Release ST 320
WebAS Release WAS 6.20

SAP Solution Manager 3.1=
ST Release ST 310
WebAS Release WAS 6.20

You can check out this SAP Wiki page for links to the main support package stacks of Solution Manager: https://wiki.scn.sap.com/wiki/display/SMSETUP/Central_Correction_Notes

SAP Solution Manager Central J2EE Monitor Bug

There is a small bug in the ABAP code when registering a SAP system to be monitored in a central system (e.g. Solution Manager) in transaction RZ21.
This was found on a Solution Manager 7.1 system.

The scenario is:
You try and register a remote monitor entry in RZ21, you enter the message server details of the system, the password for the CSMREG and the <sid>adm user, then click Save. The screen gets to the “generating logical ports…” section but you notice that it mentions a non-existent instance number for the system it’s generating the ports for e.g. instance 00, instead of 01.
At the end of the process, you get an error about invalid XML or an XML error in the error message panel.

The reason:
If the SAP system to be monitored, has an instance which is using a HTTP port that is less than 3 digits (e.g. port 80), then the ABAP code in the Solution Manager, incorrectly determines the instance number of the instance to be “00”.

To get around the issue, the ABAP debugger had to be used to manually adjust the instance number prior to it being saved.

Create a breakpoint in the code as follows.
Use SE38 to display the source of include LSALWS_CONFIGF01:

Scroll to line 1276:

Click to add a new session breakpoint:

Then, before you click “Save” in RZ21 after entering the message server details and passwords, type “/h” into the command bar:

Then click Save in RZ21.
Once the breakpoint line is reached, the debugger will be launched and displayed.
Change the value for the variable “ws_instance_list-inst” from “00” to the correct instance values (in our case it was “01”), then continue the execution from the debugger: and the entries will be created correctly.

For systems with multiple instances, you need to change both instances during the loop so ensure that you do not remove the session breakpoint until the save process is completed.

If you have tried to register the system in RZ21 before, and it failed, there may be an invalid entry now present in the Topology view in RZ21.
Simply delete the invalid segment from RZ21.

DATA ls_guid type DSWPS_DTM_DT_ALLDT_DISPLAY-ENTRY_GUID. CALL FUNCTION ‘FDSWP_DELETE_WORKMODE_DTM’ DESTINATION ‘NONE’EXPORTING IV_WORKMODE_ENTRY_GUID = ls_guidIMPORTING EV_DELETED = lv_error.WRITE: lv_error.

DATA ls_guid type DSWPS_DTM_DT_ALLDT_DISPLAY-ENTRY_GUID.

CALL FUNCTION ‘FDSWP_DELETE_WORKMODE_DTM’ DESTINATION ‘NONE’
EXPORTING
IV_WORKMODE_ENTRY_GUID = ls_guid
IMPORTING
EV_DELETED = lv_error.
WRITE: lv_error.