This is the 2nd part of the blog
http://scn.sap.com/community/it-management/alm/solution-manager/blog/2014/01/21/sap-crmsolman-charm-multiple-target-agents-via-sap-workflow--minimal-abap-development
Doing a recap, so far we have explained how to create the subtype of BUS2000116 and the events.
We continue with Tasks, Rule and HR evaluation paths.
4. Tasks.
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.
5. Rule.
The specification we got from our it management: For RfC Phase Validation, obtain from the HR Organizational Unit the RfC Requester works for, the Team Lead and the Delegates. Those are to be the WF Task Agents. Exception: If the RfC Requester is not a Team Lead, but a Delegate, that Delegate will not be a Task Agent.
It is essential for our ChaRM solution to work, that we have a HR Structure in place. You can copy and maintain it up-to-date via ALE from your ERP Production to SolMan, or you can download/upload it from the same source and target (which does to provide maintenance capabilities), or as in our case, where we have a big organization but a small group of individuals who deal with ChaRM, create our own Org. Structure in SolMan, where we could also add our own relationships to complement our needs. That is a simple exercise you can do with transaction PPOMA_CRM. Should not take you longer than half a day to setup a structure of 100 people with basic relationships.
If you need more details, please reply to this blog and I will add that section. I will avoid it for now as there is still a lot of work to add.
One of our Org. Units looks like this:
![PPOMA_CRM1.gif]()
You can see a couple of things on the screen:
- The Boss is the Team Lead. (The one with the hat)
- There is a Delegate Position (denoted with an S), that has 3 BP-Users assigned to it.
- There is a Member 4, who is an independent delegate.
- The last 2 items will be used to demonstrate that you can have 2 approaches to designate somebody as Delegate of a Team Lead, either by adding a relationship between a Position and the Boss' position, or by dropping other BP-US to a Position that is already a Delegate. The former is what you see with position Member 4, and the latter what you see with Position named Delegate, in which we dragged and dropped BP-US Member 5 and Member 6, respectively. Delegate Number 1 was not dropped there. It is the BP-User that held that Position from the beginning.
Now, PPOMA_CRM allows you to create Org Units, Positions, and to add BPs and Users, but there is no way to define there Delegate and Team Lead relationships. That is done using transaction PO10 (for Org Units) and PO13 (for Positions).
As you see below in transaction PO13, we created a relationship A311 between the Position (S) 50001385 and the Position 50001382 to reflect what we call Delegate of and SAP calls Substitute. If you see the diagram above, S 50001382 is The Boss (Team Lead).
![PO13_1.gif]()
Now, let's look at the view from The Boss' perspective. There are 2 Ss that are Delegates/Is substitute of S 50001382 (Relationship B311), and also 50001382 Manages OU 33333339 (Relationshiop A012)
![PO13_2.gif]()
Let's pause for a moment to explain the concept of A and B. A relationship in HR uses a number, e.g. 311, but if the relationship is seen from a lower object to a higher object in the Org Structure, SAP uses the prefix letter A, and they use prefix B to describe it from the opposite object. That is why in the example above, from the Team Lead's perspective, the delegates are seen as Bs, and the fact the the Team Lead is the Manager of an Org unit, is seen as an A(005), because the Manager is at a lower level than the Org Unit being managed.
Note: When you create a relationship like B311, the respective A311 is created in the Delegate's Position, hence you have to worry about only one-way of relationship to create.
Other element to keep in mind from the picture above is that as you can see the Position (S) is between the Org Unit (O) and the Central Person (CP). That means that so far we have a structure that seen from top to bottom looks like O-S-CP. However, the picture from PPOMA_CRM does not reflect the CP relationship, but it reflects BP and US depending on S.
The connection of all this is in tables HRP1000 and HRP1001 (infotypes 1000 and 1001 - tables that store HR data). For our case in table HRP1000 we see that there is an entry for OBJID S 50001382, it shows the relationship A008 (holder) with object CP (Central Person) 50000776.![HRP1001_1.gif]()
Going back to HRP1001, but this time searching on OBJID 50000776 we find 2 erlationships B207 and B208. If you check in transaction OOVK, those relationships are both Is identical to. That means that CPis identical to BP, and identical to US. That concept will help for the next step.
![HRP1001_2.gif]()
Back to our exercise, we need to retrieve the Team Leads and Delegates of an Org Unit. In order to do that we need to create an HR Evaluation Path if the ones already there do not comply to our goal. FYI, you can use report RHWEGID0 to find out Evaluation Paths based on what you are looking for. For the case, we looked for any EP that started in O, and went to US using S. None of them worked for us.
So, using the transaction OOAW we created the following EP, which looks more dramatic than what it is. In plain words: We start with an Org Unit (O) to search via relationship B012 the Position (S) that manages it. From that S using relationship B311 we look for the Ss that are substitutes (Delegates). For all retrieves Ss so far using relationship A008 we retrieve the Central Persons (CP) holders of those Positions, and from there also the correspondent BPs and USers.
![OOAW_1.gif]()
To test that EP we run report RHSTRU00. Provide the Org Unit and the Evaluation Path.
![RHSTRU00_1.gif]()
We obtain the result, that if you compare with the PPOMA_CRM picture provided top conclude we only retrieved the Boss and the Delegates, which is what we are looking for.
![RHSTRU00_2.gif]()
With the same approach we created another EP that retrieves the Organizational Unit when a user is provided. The reason for creating it and not using, e.g. the SAP delivered one WF_ORGUN, is due to the way the HR data is created and stored in table HRP1001 when using PPOMA.![OOAW_2.gif]()
![OOAW_3.gif]()
As you see above, WF_ORGUN requires the existence of a relationship between USer and P (Person), but in SolMan PPOMA_CRM the additional entry it creates in HRP1001 when hooking up a Position to a BP and a USer, is a relationship between that Position and a CP (Central Person), and not P (Person). Two different HR objects.
How to test that the EP works fine was already explained, so please take the same approach.
With that in place the only pending object before we create the Rule, is the FM that will retrieve the Agents from the Org Structure.
The FM has a BRFPlus call that will be explained at the end of this document, so that we stay focused on the Rule. That text in Italics, can be changed with 3 select statements that:
1. Retrieve from HRP1000 OBJID where SHORT = lv_rfcrequester . OBJID is the actual CP.
2. Retrieve from HRP1001 SOBID, where OBJID = the above CP and SCLAS = 'S'. That SOBID is the actual Position (S) of the RfC Requester.
3. Retrieve again from HRP1001, where OBJID = the above S and SUBTY = A012. If you get a record, the Requester is actually Team Lead. If not, it is a Delegate.
Note: You still need to include the fields BEGDA and ENDDA to retrieve active records, but we will show that when we explain BRFPlus.
function zch_retrieve_teamlead_delega01.
*"----------------------------------------------------------------------
*"*"Local Interface:
*" TABLES
*" AC_CONTAINER STRUCTURE SWCONT
*" ACTOR_TAB STRUCTURE SWHACTOR
*" EXCEPTIONS
*" NOBODY_FOUND
*"----------------------------------------------------------------------
include <cntn01>.
tables crmd_orderadm_h.
data: lt_usersorgunit type swhactor,
lv_numlines type i,
lv_isteamlead type boolean,
lv_objid type crmt_object_guid,
lv_rfcrequester type crmt_partner_no,
lv_rfcrequesterou type actorid,
it_usersou like lt_usersorgunit occurs 0,
lv_usersouheader like lt_usersorgunit,
it_userstldl like lt_usersorgunit occurs 0,
lv_userstldl like lt_usersorgunit,
lo_factory type ref to if_fdt_factory,
lo_function type ref to if_fdt_function,
lo_context type ref to if_fdt_context,
lo_result type ref to if_fdt_result,
lv_result_string type string,
lx_fdt type ref to cx_fdt.
field-symbols: <ls_message> type if_fdt_types=>s_message.
**Read parameter - RfC # GUID from the WF container
swc_get_element ac_container 'Object_ID' lv_objid.
* As this FM is called from an RfC, then the RfC will always exist in table crmd_orderadm_h,
* hence there is no needd to check for SY-SUBRC =0.
select single guid from crmd_orderadm_h
into lv_objid
where object_id eq lv_objid.
* As Team Field is mandatory in the RfC, it will always be an entry in crmd_order_index for it.
* Field PFT_7 with an X means that the Partner_No entry asociated in the record is the RfC Requester.
* PFT_8 .. TeamLead; PFT_16 .. Change Manager; PFT_1 ... Sold to Party, etc.
select single partner_no from crmd_order_index
into lv_rfcrequester
where header eq lv_objid
and pft_7 eq 'X'.
* Now we use the SAP FM to retrieve the Org Unit that Team Lead works for.
call function 'RH_STRUC_GET'
exporting
act_otype = 'US'
act_objid = lv_rfcrequester
act_wegid = 'ZCH_ORUN'
tables
result_tab = it_usersou
exceptions
no_plvar_found = 1
no_entry_found = 2.
* others = 3.
describe table it_usersou lines lv_numlines.
* Below there should be a logic to deal with a user that belongs to more than one Org Unit (OU)
* but we leave it like that for now, as that is supposed to be identified at the initiation
* of the RfC. For now, we assume each user belongs to only one OU
loop at it_usersou into lv_usersouheader.
lv_rfcrequesterou = lv_usersouheader.
endloop.
* We now need to find out if the entered TL is actually a TL or a Delegate. For that we use a BRFPLUS
* function.
* Init BRFPlus
lo_factory = cl_fdt_factory=>if_fdt_factory~get_instance( ).
lo_function = lo_factory->get_function( iv_id = '001E0BEA00C41EE39E93CE6349D5E0FC' ).
try.
lo_context = lo_function->get_process_context( ).
lo_context->set_value( iv_name = 'BP_INPUT' ia_value = lv_rfcrequester ).
lo_function->process( exporting io_context = lo_context
importing eo_result = lo_result ).
lo_result->get_value( importing ea_value = lv_isteamlead ).
catch cx_fdt into lx_fdt.
loop at lx_fdt->mt_message assigning <ls_message>.
write / <ls_message>-text.
endloop.
endtry.
* End of BRFPlus
* We keep in lv_isteamlead if the BP entered in the TeamLead field of the RfC is actually a TL or not.
* If it is not, then that BP will not be notified when the RfC enters in Phase Validation, as another body
* than that Delegate must review the RfC, either the actual Team Lead or any other Delegate of the
* Org Unit they work for.
* We retrieve the Agents based on the list of Team Leads and Delegate of the Org Unit.
call function 'RH_STRUC_GET'
exporting
act_otype = 'O'
act_objid = lv_rfcrequesterou
act_wegid = 'ZCH_TLDL'
tables
result_tab = it_userstldl
exceptions
no_plvar_found = 1
no_entry_found = 2.
* others = 3.
append lines of it_userstldl to actor_tab.
* Remove any other entry that is not USer.
delete actor_tab where otype ne 'US'.
describe table it_userstldl lines lv_numlines.
if lv_numlines is initial.
raise nobody_found.
* If more than one Agent is found and the TL in the RfC is actually a Delegate, remove it
* from Agents.
elseif lv_numlines gt 1 and lv_isteamlead eq 0.
delete actor_tab where objid eq lv_rfcrequester.
endif.
endfunction.
Other important screens from the FM.
![SE37_1.gif]()
![SE37_2.gif]()
In transaction PFAC create a new rule. Use the create button
Note: The recommendation is to use prefixes for all the objects you create. We used "ZCH_" in ours. Below are the different tabs.
![PFAC_2.gif]()
![PFAC_3.gif]()
![PFAC_4.gif]()
The rest of the screens are standard. Add the description at your leisure in the respective tab.
Let's test the Rule.
We have a RfC where user ending 56 or Delegate Number 1 is the Requester, but that BP is not a Team Lead, but a Delegate. The rule should retrieve in WF format, all the Agents, Team Leads and Delegates, except for user ending with 56 (Delegate Number 1).
![PFAC_7.gif]()
![PFAC_5.gif]()
![PFAC_6.gif]()
With this we complete the Rule.
Part 3 contains details on the tasks, rule and our full WF ready for testing.
http://scn.sap.com/community/it-management/alm/solution-manager/blog/2014/01/23/sap-crmsolman-charm-multiple-target-agents-via-sap-workflow--minimal-abap-development--part-3-last
. 
, one of my favorites is which one you can see on page 4 of that overview 
