This is the 3rd part of this blog.
SAP CRM/SolMan ChaRM: Multiple Target Agents via SAP Workflow - Minimal ABAP Development
Second part can be accessed: http://scn.sap.com/community/it-management/alm/solution-manager/blog/2014/01/22/sap-crmsolman-charm-...
In the link it appears the word last at the end, because with this we consider you have all the elements we researched to do our work and begin working with WF in ChaRM. Part 4 will show how to test the WF as well as running the full scenario using the Web UI plus getting additional details behind the WF scene: How to trace and troubleshoot.
So far we have explained how the delivered WF for Approval of the RfC in ChaRM looks behind the scenes, the creation of the subtype of BUS2000116, the events we need for our WF, a brief description about the 2 tasks we use in our WF, and the rule to retrieve the Agents that are to perform the RfC Validation, which includes some theory about evaluation paths.
We continue the process with our Validation WF in detail; which we will test out in Part 4. As a bonus there we include how we build a BRFPlus function that finds if a BP is Team Lead or not in the HR Organizational Unit he/she belongs to. Why BRFPlus? Because to work with BRFPlus you do not need a developer key. That gives you some freedom when you do not have a developer to work with you or you do not do ABAP but know basic SQL statements. For that reason with BR+ you do not get stopped on your work.
6. Our Workflow.
The first task is to create the condition that will trigger our WF. Many ways to trigger an event exist. There is an ideal in CRM with no ABAP involved.
Launch transaction BSVW and select Customer Settings. We created 2 entries there for our WF: One that triggers the event that starts the WF, the other one that starts the event that terminates the WF when the RfC phase moves from Validation to To be Approved. The images should be self explanatory.
1st event.
2nd event.
Note: It is very possible there are cases in which you need to have more than one User Status that triggers the termination event. You should check what are the possible subsequent Actions (next phases) within the RfC of Change Object phase you want to introduce a WF.
Let's now complete the 2 tasks for our WF, which we copied from the SAP standard ones, as mentioned in Part 2.
(There are 2 main tasks in our workflow as described in part 1. We copied both 2 being used by the SAP delivered WF WS17100016. Some slight modifications were done to ours.
4.1 Task TS999000039 is a copy of the SAP delivered one TS17107927 (Get current step information). The copy of that task was done via transaction PFTC. Although it is the same in essence, we changed some texts to our convenience. We will see them later on once we get back to WF.
4.2 Task TS99900035 is a copy of the SAP delivered one TS17107930 (Approve Request for Change). The different piece in this task is that we created a rule to retrieve the Agents that are to be notified when the RfC moves to phase Validation.)
Via transaction PFTC we call task 999000039, Retrieve RfC Data. As you see we only changed the description, which takes us to a recommendation we have for you. SAP WF comes with hundreds of function modules, rules and other objects that are re-usable. That reduces your efforts considerably. For example, FM CHANGEWITHDIALOG, which we use below. Initially we thought we were going to have to create a new method to assign our newly created Task to the Agents. As step 1 of our trial we approached with caution and tested our task using that method delivered by SAP for the original task we copied from. It did the work for us at the Validation phase.
Probably that may not be a big deal for you, but we have faced the same situation at other occasions, and learning about WF as some of you using ChaRM or CRM may be probably doing now, recycling objects is a heck of a relief. WF is huge and believe us, it is a great tool that allows you to manipulate almost any scenario you can imagine without harming the integrity of the SAP Product you work with.
Back to work,
Finally, important to highlight that Synchronous tasks are executed immediately.
The second task T99900035. We re-use a SAP delivered FM that fits our needs. It is responsible for creating the tasks for the Agents. It is asynchronous as we do not know when the Agents are going to check the RfC to Validate it. While this task is active, the WF stops and waits for resolution.
Below the tab with the Terminating Event data. Besides the task description, this is probably the main reason we had to create this task as a copy of the task delivered by SAP in the Approve RfC step of the WF. The event we use is different.
With the 2 tasks available we are ready to create our WF using transaction SWDD. As explained before, when you create a WF Template, if there are Activities you want to add (Tasks), just grab the icon from the right hand side of the screen, below Step Types that Can Be Inserted, the correspondent Activityicon, and place it in the middle of the flow window on the right hand side, between Workflow Started and Workflow Completed. When you create a WF for the first time, there is already an inactive Activity (Task) there, hence you may only need to drag and drop from a second task on (in a two-task WF)
FYI, there is a bar on the right hand side of the screen that gives access to different WF menus. We used 2 for our exercise: The first one and Workflow Container.
In that window, switch to WF Container as we need to add an element to our container (Container is where parameter values are kept during the WF execution). There is an object BUS2000116 delivered by default when the WF is created, but which is useless. We had to create a new one, almost with the same configuration, only different name and mandatory as it is a requirement for the WF to start.
To create the object, follow the screens.
The screens below complement are accessed when you click on the Hat. They contain the WF description and the triggering event.
Note: Do not worry about the variables at this moment. Below you will get to know about bindings.
The other general tab is the Start Event, which shows the WF trigger event. The A (Active) green square on the right hand side refers to the automatically created entry in transaction SWE2 (see further down). The two little green mail envelopes show the bindings or parameter values that are passed from one object to the next in the WF. For the case below, those are the parameters passed from the event to the WF: 1. The so called _EVT_OBJECT is passed to the WF mandatory Container object we created above, REQUESTFORCHANGE. 2. The _EVT_CREATOR is passed to the _WF_INITATOR.
A couple of views of SWE2, which entries are automatically created when you add the event to the screen above and activate the linkage.
FYI, as long as the linkage is active, the event will always start the WF. In other words, you could have a WFbeing repaired and you can temporary remove the linkage in SWE2 directly or clicking in the green square in the screen above to turn it to gray or grey (color spell depends whether the reader is from America or from England or a former English Colony). That will avoid the WF from start, no matter if the event is still triggered. Very useful, because you can have the same event starting many workflows, and by this approach you do not affect the other WFs functionality while fixing one of them.
First Task: To access it, we double-click on it.
In the Control Tab the Task we created is entered. Adding the task, will add the task description below, the fact that it is synchronous and run in the background.
Let's take a look at the bindings (the button under task number). Most of the bindings, at least 90+% are automatically added by default or when you click the generate button, they get added for you. All depends on the task definition and the object it interacts with (WF, rules, e-mail, or other steps). You may only need to manually bind when you have created your own objects in the Container, which SAP sometimes can not recognize. We will visit that scenario below. In principle you pass Container elements from one object to another so that the values do not get lost, though WF does not loose track on the core ones, e.g. REQUESTFORCHANGE. For that case, you only pass them from the object to the WF if you updated them. Still you need to pass them from, e.g. the WF to the Task, because the task may have a method that needs to read from the container.
The last tab in this first task is the outcome. We will get a better understanding in the next task, as this one is background and basically it is an outcome created by default.
Second Task: To acccess it, we double-click on it.
In the Control Tab the second Task we created is entered. That will add the task description, which is what the Agents will get in the notification of the task they access either in the SAP Business Workplace or in the Web UI's Worklist. You can see also that the Agents are defined by the AC Rule we already created.
Pressing the button under the task, we get the bindings between the WF and the Task and the returned values after the task is executed. Remember that no values back does not mean data gets lost. Most of the data in the container is retained always in the WF.
The rule we created had an container parameter for import, the RfC #. When the rule is added to the WF, the binding window has that object available in list of objects of the rule window. It is our duty to bind it to an element of the WF, for which we drag and drop on both windows the correspondent matching partners.
Note: We tried to pass the GUID, but we still need to learn how to deal with RAW16 types, as it looks like they require some kind conversion to 32 characters or vice versa. So farm the RfC # does the work for us.
Let's review some of the rule screens.
In the logic of the method the rule uses, we retrieve that RFC # from the rule's container. That is the way you retrieve a parameter from a container. Knowing that, opens up door to transfer anything you need: single variables, tables, anything.
And that is all you need in the WF.
In the next and final blog of this topic we show you how to test the WF with SWDD and we will test the whole ChaRM functionality involved, as well.
- SAP Managed Tags:
4 Comments
