Interesting "exploit" in standard SAP Solution Manager ChaRM

[bruno_esperanca]

It's been a very long time since I've written anything here. I guess I'm still digesting the fact that I'm not professionally or actively developing in ABAP anymore.

But life moves on and I'm quite motivated to take on my new position and explore SAP Solution Manager in more detail.

Recently I have come across a very interesting situation, which might be very relevant for all of you who are using ChaRM in SAP Solution Manager.

 

"What happened?"

As is recommended (or pretty much mandatory), we have copied the standard normal change transaction type SMMJ into the classic ZMMJ type. We tried to stay as close to the standard as possible, but as we don't possess a pre-production system (yet), many of the preliminary import request related statuses were not relevant to us, and as such, we trimmed a few of them down. Basically, after the Successfully Tested status (which we renamed Released for Production), we have a Preliminary Import Requested and that's it.

 

ZMMJ Preliminary Import without PreProd

 

The process should be relatively simple. After a change is successfully tested, it will wait for the transport requests to be imported into the productive systems by a job (executed by the IT-Operators). After that, either the status Imported into Production via the action Set Production Status, or, the better alternative, is to have an automatic feedback trigger set up. If the action Set Production Status is executed but the changes were not imported into production yet, you should get an error message like this.

 

Error Message When Trying to Set Production Status

 

If the change cannot wait for the next import job execution, there's the option to request a preliminary import, which goes to the IT-Operator. If the IT-Operator approves and imports this into the productive system, great! We're done!

However, sometimes the IT-Operators don't like what they see. Maybe it's a change that will crash the productive system. Maybe it will disrupt the users too much. Maybe some background jobs have to be switched off. Regardless of the reason, the preliminary import was rejected, and the change should go back to Successfully Tested status, and it does.

So far so good. Now something strange happened. The change was imported! How could this be?! We can clearly see in the text log that the preliminary import was rejected, but then it was simply imported, without any import job running!

 

Preliminary Import Rejected... and Imported!

 

"How on Earth was that possible?!"

Here comes the technical and interesting part. In fact, if you check the actions of the Set Production Status action, it should trigger an import, if we are talking about a preliminary import request.

 

Action to Import Preliminary Request When Setting Productive Status

 

And the system will know that we are talking about a preliminary import request, because when this is requested, a flag is set on table TSOCM_CR_CONTEXT.

 

Preliminary Import Flag on Table TSOCM_CR_CONTEXT

 

Now, when the preliminary import request is rejected, and the status is set back to Successfully Tested, there is an action called PRELIM_INIT which should reset the flag.

 

Action PRELIM_INIT which resets the preliminary import flag

 

However, and here finally we get to the real culprit, the action which is executed to reset the change to status Sucessfully Tested, action SMMJ_CANCEL_PRELIMIN_IMPORT_MJ - "Cancel Preliminary Import", has the parameter RESET_STATUS set to true!

 

Reset Status Flag Set to True in the Cancel Preliminary Import Action

 

And this skips all consistency checks and actions! So the flag is never reset, and next time someone executes the action Set Production Status, it will trigger the import of the changes!

 

"Oh my God! What can we do now?"

Well, the solution is simple. Just remove the RESET_STATUS parameter from your "cancel preliminary import" action, whatever it is. Make sure to test your process thoroughly to ensure there are no regressions, but as far as I can tell, for us it worked seamlessly removing this parameter.

By the way, SAP was informed via OSS message and this should eventually be fixed also in the standard configuration, but you might wanna go ahead and fix this now rather than later.

Cheers!