ABAP developers which cannot create or release transport requests behave somehow like truck drivers with heavily tattooed arms who are getting impatient when the loading of their lorry halts.
This happens for example in the ChaRM when the maintenance cycle is locked. But implementing a really nice idea of Woody Wu from the SAP Solution Manager Development Support will help to get out of a tight spot.
This is also a good example for a PPF action scheduled via BAdI (for Solution Manager 7.0 EHP1) and we show how to extract the original message variables from a message.
The history of this blog series:
\ Pep Up Your ChaRM – Part 1: HowTo Create a Smart e-Mail Action
\ Pep Up Your ChaRM – Part 2: a CRMD_ORDER Slimming Cure
Pep Up Your ChaRM – Part 3: Turn Cinderella PDF-Mails into Pretty&Usefull Ones
Pep Up Your ChaRM – Part 4: How To Avoid a Nag Screen
The Missing Link
As many ChaRM customers do, we use only the urgent correction (SDHF) as described in SAP note 952803 to transport changes from the development to the downstream systems.
During the process of the SDHF change document one crucial step is the creation of the hotfix task list and of the links to it and to the maintenance cycle document (SDMN) which can be found after pressing the document flow button:
But if the SDMN transaction type belonging to the maintenance cycle (1014 in our example) is locked – guess it or not, this happens ofter than needed -, the link to it will fail, and the step of the creation of the hot fix tasklist will not be executed, resulting in a change document with a red led showing the error message CHM1_ACTION_LOG 030 with a text which is meaningful only to the change manager:
You can now execute the PPF action “Recheck Correction” starting a thorny path of save and recheck actions (we hope that in the meantime the lock of the maintenance cycle was released) which is really difficult to explain to normal ChaRM users, or you read this blog and implement an action which does the job using internally the service report (following the nice idea of Woody Wu from the SAP ChaRM development support).
And How to Supply It
In order to offer a rescue action we have to do two main steps: create the PPF action, schedule this action.
The PPF Action
We need a PPF action of type Method Call. This is done implementing the filter-dependend BAdI EXEC_METHODCALL_PPF. The name of the PPF action method is simply a filter value for this BAdI.
To implement the BAdI you can use the IMG with this path: SPRO -> Customer Relationship Management -> Basic Functions -> Actions -> Actions in Transaction -> Business Add-Ins -> BAdI: Processing Methods. You will get a dialog where you can add your own implementation and your filter value.
If you have already created an own implementation you have to deactivate it before you can add a new filter value:
After having added the new filter value you can (re-)activate your implementation.
On the Interface tab you have to insert your implementing class. In the method IF_EX_EXEC_METHODCALL_PPF~EXECUTE we will insert our rescue coding:
The rescue coding is rather simple:
The Action Definition
To define the action we use transaction CRMC_ACTION_DEF (see Part 1 of this series), but this time we select the rule type Conditions Using Business AddIn (BAdI):
The Sort Order For Display = 1 is a psychological trick to draw the attention of the user to it.
But please pay attention that the Action Merging allows only one execution (see later). Also this time we will select the Method Call processing type and insert the filter value defined in the last step as Method:
In order not to irritate the ChaRM user we want to offer this special PPF action only when the Business Object links are missing. To accomplish this we have to create a scheduling via BAdI.
This time we have to implement the BAdI EVAL_SCHEDCOND_PPF.
I didn’t find an IMG entry for this activity so we directly start with transaction SE18, insert the BAdI name and select Menue -> Filter value -> Create (or Change if you have already an own implementation). It is the same handling as described above:
This time the coding is more complex. First we have to find the message which should trigger the scheduling of our action. Then we have to extract the object id of the locked cycle and then we have to test if the cycle is still locked, because we can execute our rescue action only one time (see later). So we would not splash our dart uselessly.
And this is the function module used to fillet the message into it’s constituent parts:
We start transaction CRMC_ACTION_CONF, open our action profile in change mode and press the Create button:
We select our just created condition as schedule condition (via value help) and save.
Now we are done.
We can test this new action opening the cycle in edit mode this way: transaction SOLAR_PROJECT_ADMIN -> Select ChaRM Project -> Tab System Landscape -> Sub Tab Change Request -> Button Show Service Desk Transaction -> Edit mode. Now the cycle is locked. If a user tries to create or put into development a hot fix he would get the error message as shown above.
When the lock is released the user might now execute the new PPF action and automagically all missing parts are created and the red led disappears.
It is important to comunicate to the users that they should not use the normal Recheck action which is also offered in case of error because this action would delete our trigger message which contains the object id of the cycle transaction.
A Valley of Despair
“More than any time in history, mankind now faces a crossroads. One path leads to despair and utter hopelessness, the other to total extinction. Let us pray that we have the wisdom to choose correctly.”
I don’t want to hide a big problem.
In my first implementation I defined the PPF action ZOG_CREATE_BO_LINKS as “One Unprocessed Action for Each Action Definition“. When executed only one time during a session this worked without any problem.
But when executed more than one time, may be because during the first execution(s) the cycle transaction was still locked, the action itself worked too, the error condition was corrected by the service report, but after the execution of this action there was a short dump caused by the exception CX_OS_DB_DELETE fired in the method CA_TRIGGER_PPF -> MAP_SAVE_TO_DATABASE.
Following the SAP note 896173 and the nice Blog of Thorsten Franz
Calling Function Modules in Parallel Universes I tried to move the SUBMIT of the service report into an RFC enabled function module which I called via destination ‘NONE’. The dump changed now to a dump CX_OS_DB_DELETE in Method CA_SF_MAIL_PPF -> MAP_SAVE_TO_DATABASE (yes, in status E0002 “In development” I schedule a mail action which will start at the next status value (“To be Tested“).
It was obvious that the fragile buffering of the PPF actions was out of sync with the database. I tried to reinitialize the CRMD_ORDER session, to refresh it’s buffers, but I always got short dumps.
Playing with “Delete After Processing” in the action definition didn’t work either.
Then I tried to define the processing time of the action as “Immediate processing“: The short dumps now disappeared, but the error messages did not. I tried to delete them at every occasion, I tried CRM_MESSAGE_INITIALIZE, I tried to schedule internally a recheck action, but nothing. Also in this situation it was obvious that the CRMD_ORDER session didn’t get the changes coming from the service report.
After some playing with the transaction there was the strange situation that the hotfix was ok (no status I0030), all the PPF actions were offered correctly, but the red Led with the obstinate error message was still existing until the transaction was saved.
So facing the fact that this PPF action can be executed only one time without generating a short dump I decided to put some logic into the schedule method so that the PPF action is displayed only when it will probably not fail.
May be someone of the readers knows a method or an event to force a CRM transaction to refresh it’s buffers with the database without generating a short dump.