SAP CRM/SolMan ChaRM: Multiple Target Agents via SAP Workflow – Minimal ABAP Development
The present blog intends to consolidate different areas of expertise around SAP Workflow (WF) in SAP ChaRM.
Case: You want to have more than one Agent notified of a SAP WF Task in the processing of a Request for Change (RfC), after that RfC has reached a new phase.
Expanded Scenario: SAP ChaRM comes with a WF when the RfC is set to To be Approved. We will be explaining how to add a new WF for another phase change when the RfC is moved from Created to Validation.
What will you learn or review at the end of this blog?
1. SAP Workflow basics (Tasks – Rules- Bindings).
2. SAP Object Types – Delegation, Events.
3. SAP HR Evaluation Paths.
4. SAP BRFPlus.
5. SAP Function Modules.
- Use of basic Functions to efficiently retrieve HR data,
- Refine user retrieval with the exclusion of not needed records,
- How to call a BRFPlus function.
Task for you at then end: To apply the acquired knowledge to create a new WF to submit multiple e-mail notifications. Once the basic concepts about WF are understood, the sky is the limit.
Clarification. The SAP Workflow we are referring to in this document is the already known SAP Workflow being used since the 90s. That WF involves some design like the one you do when using MS Visio as well as ABAP developments. In SAP CRM, the term workflow is used as the flow a business transaction goes through. In the case of ChaRM the CRM workflow involves different phases the RfC goes through like: Created, Validation, To Be Approved, Approved, etc. The latter is not the workflow we refer to in the present document, though we are going to use it, by explaining the former.
Transaction Type used: ZMCR (copy of SAP’s SMCR), and ZMMJ (copy of SAP’s SMMJ).
Version: Solman 7.1 SP9.
Waiver: Many areas are covered in the present blog and we are not bringing this to you as “the solution” for multiple notifications in ChaRm. The fact is that now that we are using SAP WF in many areas of ChaRM, and calling the same Evaluation Paths and BRFPlus functions at various places, we intend to share the experience with our colleagues. How many times they have not helped us out? Countless.
If you find the overall WF approach too overwhelming, takes the bults and pieces that you consider apply to your case.
Enjoy and have a safe trip!!!
With all that, let’s get started.
There has been a lot of good debate in SCN on how to notify more than one user (Agent) when an action in an RfC needs to be taken care of. As we know, in SAP there are many ways of producing the same result, that why we love it. We found a niche that could open a huge door of possibilities for people working in SAP CRM or ChaRM. We hope for that with no presumption, as probably many other ones already use SAP WF in CRM.
Due to the revamping of SAP Workflow in recent years there are many new possibilities. SAP added to the WF recipe the Business Object Repository (BOR), besides the already known ABAP Classes. With that, SAP provided a carrot in front of us, the hungry dogs who run after it to get it and chew it to develop a better vision due to the Vitamin A in it. The intention is then to take one more step and consolidate different areas of expertise so that we all get a better understanding of a component of this tool that provides bread onto our tables, or a new gadget to buy.
1. Explanation of how the delivered SAP WF works when the RfC is switched to phase To Be Approved.
The main two elements that are involved are:
1.1 Via Transaction CRMC_ACTION_CONF, there is an action that runs in the background when the RfC is To be Approved.
That I1387 in the Tab Start Condition is a System Status. FYI, there are User Statuses and System Statuses when referring to RfC or Change Document processing. User statuses begin with an “E”. They can be found in table TJ30 when searching for Status Profile ZMCRHEAD or ZMMJHEAD.
The get to the System Status, one way is through the IMG: SAP Solution Manager > Capabilities > Change Control Management > Standard Configuration > Transaction Types > Status Administration > Define Status Profile for User Status > choose ZMCRHEAD > As you see above, the column CRM_VRGNG refers to Business Transactions (BT). For phase To be Approvedthere is a BT C4AP. Based on that, from the menu choose Environment > Transactions > look for C4AP and double-click on it > Page down and you will see that the System Status I1387 is set when the RfC is moved to phase To be Approved.
In the background as reflected in the blog, http://scn.sap.com/community/it-management/alm/solution-manager/blog/2014/01/20/sap-charm-basic-business-transaction-table-storage-diagram, there is a table CRM_JEST that stores the System and User Statuses during the lifetime of a RfC. In the example below that you can corroborate with the information provided above, the RfC shows some Active Statuses (the ones with no ‘X’ in column INACT). They are: User Status: E0015 (Release for Development), and System Statuses: I1003: PROC (In Process), and I1385: CAPR (Approved). I1387 CAAP is inactive, as that RfC was already approved.
Note: You can directly access the Business Transactions via transaction BS32, or the System Statuses via transaction BS22. Why did not I mention that before the long walk!!!
Now, back to the Transaction Type in CRMC_ACTION_DEF, the tab Processing Details shows that the method being executed is APPROVE_RFC_VIA_WF. Press the right button as shown below to get access to that method. Then go to the tab Interface and double-click on the Method EXECUTE (our apologies as we are not adding all the screens, because there is still plenty of work to add to this blog). We are just at the beginning.
This method is the one that deals with the RfC approval. We want to highlight just 2 fundamental calls there that hook up to the SAP WF. The method uses FM SWE_EVENT_CREATE to trigger 2 events. The second one highlighted is requesttobeapproved and the first one is stepexecuted.
In transaction SWE2 we can see what WF (Receiver Type) is launched based on events. There is an entry there that after double-clicking on it looks like this:
Note 1: Important that the linkage is active for the Event to actually launch the WF.
Note 2: It is assumed we all understand that the Object Type being used in ChaRM is BUS2000116. If we have time, we will provide more details, but for now let’s accept as a fact. FYI, Object Types are administrated via transaction SWO1 (letter ‘O’).
Let’s now access the WF mentioned above, WS17100016 using transaction SWDD to get to know the 2 elements that connect all this. We will not go into more details of that WF, for now.
As you can see by clicking on the Hat icon to get access to the main tabs, the tab Start Events, shows that the event REQUESTTOBEAPPROVED is the one that starts this WF. The column Active with the green square is actually the entry Linkage Active of the previous screen. In other words, in your experience with WF, you could create lots of WFs and Events, but only have active WFs when you activate the specific linkage. That is a core element that shows the flexibility and ergonomics of WF.
That is one of the events. The one that starts the workflow. What about the one that terminates the WF, when the agents actually approve the RfC?
Once you do that, you will see that the task being executed if TS17107930. Double-click on that task and check the Tab Terminating events.It shows the event BUS2000116/STEPEXECUTED. When that event is triggered, it terminates this task. For the case, that action happens as soon as the RfC is approved as the method APPROVE_RFC_VIA_WF, mentioned above, contains the FM call that triggers that event.
The events are defined in the Object Type they refer to. If you go to transaction SWO1 > BUS2000116 > Display > Events, you will see the events defined for that Object Type. For SAP CRM, there are many other Object Types besides BUS20001* (CRM Business Transaction), like BUS20100* (Marketing project), or BUS1006* Business Partner.
That briefly explains the WF SAP delivers for ChaRM. Now we are going to create our own WF, briefly showing our WF to then go to each of the details in the chronological order they are supposed to exist before you put them altogether in the WF.
2. Our WF when RfC enters in Validation.
Via transaction SWDD, our basic WF looks like this. (It was based on the one delivered from SAP WF Template WS17100016).
Note: Creating a WF is quite simple. Once you get to this transaction, press the Create button. It will then provide a basic skeleton and all you need to do is to drag and drop from the left hand side of the screen, from under Step Types That Can Be Inserted, the steps, e.g. Activity, or Send Email, that you want implement in your WF Template. After that, by double-clicking on each added step, you will get to provide the details. if there are steps that you do not need any longer, just right-click on them and select Delete. At the end of each major change, the buttons Check and Generate will activate the latest version of your WF Template.
Note: WF or WF Template in this document refers to the same. In theory in SAP you do not really create a WF per se, but a WF Template, instead, based on our understanding, so far.
Click on the Hat button marked above and let’s get some details. In the tab Start Events we have an event REQUESTTOBEVALIDATED that starts our WF. That event is part of Object Type BUS2000116, though it actually belongs to subtype YBS2000116 that we created, as we are not supposed to change the SAP Standard Object Type. Details will be provided further down.
The WF has 2 main steps. One that retrieves the data from the database, and the other one that actually notifies the users (Agents) that an action is required for them to review the RfC and Validate it or not. The beauty is that the task (item) will be placed in the WebUI User’s Worklist of the agents to act up on.
Step 1. Retrieve Object Information. It is a background task. Background tasks do not have Agents assigned to them.
Step 2. We back out and select the our WF second task. Further down, we will describe Task TS99900035 and AC Rule 99900006. The latter is the approached we took to retrieve the HR users that become Agents or responsible ones to act up on the task.
Double-clicking in the task TS99900035 you can see below that there is the other event we need to care about: REQUESTTOBEAPPROVEDNEW. That event is the one that terminates the Task, which for our case will happen once the RfC moves from phase Validation to phase To be Approved.
So, we need to explain to you in order the following items:
- How to create the new events we need and how they get triggered.
- Creation of the tasks we are going to use.
- Creation of the agent retrieval rule.
Note: All the changes further down better to be done if your account has an associated developer key. There are issues in which you will not get an error, but the functionality will not be there until the account you use has that access.
We need 2 new events REQUESTTOBEVALIDATED and REQUESTTOBEAPPROVEDNEW.
If you have not done so, we need to create a subtype out of Object Type BUS2000116. Launch transaction SWO1 and follow the screens, please. FYI, Our subtype was named YBS2000116.
Save this into a request …
The next necessary step is the delegation of Object Type BUS2000116 into YBS2000116. In plain words, we are using Object Type BUS2000116 all over the ChaRM configuration, but we will be placing our enhancements in YBS2000116. We want to allow that everywhere BUS2000116 is used, the YBS2000116 content is accessible, as well. For that launch SWO1,
The next entry is tricky to be created. We do not know if it is the gui we have or what, but to add a new entry was not that simple. In the end, you should get access to create a new entry, below is what we provided after.
The new entry should look like this.
Note: If you do not do this delegation with a a user with a developer key, the delegation seems to be fine, but will not work.
Save your changes.
Now back to SWO1 let’s create the 2 events mentioned above for Object Type YBS2000116. Get into Change Mode and open up the Events folder and press the create button
Below the 2 events.
In order to be able to use those events in BUS2000116 after they are created, choose each event and from the menu: Change Release Status > Object Type > To implemented, and also: Change Release Status > Object Type Component > To implemented. That will remove the little squares on the right side of the events and they will be available in Object Type BUS2000116.
Note: You see more events because now we use WF in many more areas.
In the next part we continue with the Tasks and Rule we use in our WF.