Skip to Content

This is the 2nd part of the blog

SAP CRM/SolMan ChaRM:  Multiple Target Agents via SAP Workflow – Minimal ABAP Development

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 in the program below, can be changed with 3 select statements that cover the following:

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:  &lt;ls_message&gt; type if_fdt_types=&gt;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=&gt;if_fdt_factory~get_instance( ).
lo_function = lo_factory->get_function( iv_id = ‘001E0BEA00C41EE39E93CE6349D5E0FC’ ).
try.
      lo_context  = lo_function->get_process_context( ).
      lo_context-&gt;set_value( iv_name = ‘BP_INPUT’ ia_value = lv_rfcrequester ).
      lo_function-&gt;process( exporting io_context = lo_context
                          importing eo_result  = lo_result ).
      lo_result-&gt;get_value( importing ea_value = lv_isteamlead ).
  catch cx_fdt into lx_fdt.
      loop at lx_fdt-&gt;mt_message assigning &lt;ls_message&gt;.
        write / &lt;ls_message&gt;-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.gifPFAC_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

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Carol Thomas

    As a workflow consultant, kudoes on a thorough and complete explanation of WF from stem to stern.  No small task and you did it very well.

    Have two questions:

    Would like to understand why you defined the delegates in the organization structure as opposed to using the standard SAP substitution functionality typically used in workflow.  Is there a SOX requirement that I am not understanding?

    Using a function module, BRFplus and responsibility role (PFAC) is an interesting combination.  Did you consider using a BRFplus rule directly within the workflow as a separate task to determine the approving agents?  You can create a BRFplus task in an WF Activity step.  In addition to doing a DBselect in BRFplus you can also call a FM that can return the agents using an evaluation path.  One thing about workflow is that Agent determination is so incredibly flexible.

    Again, congratulations on an excellent thoroughly detailed solution.

    Carol Thomas

    (0) 
    1. Juan-Carlos Garcia-Garavito Post author

      Hi Carol.

      Many thanks indeed for your comment.  It is work for me that I am trying to test, at least the BRFPlus as an independent Task.

      May you update your SNC profile adding your contact information so that I can to send you an internal message via SCN?     I would like to provide the best answer so that colleagues do not get confused.

      If you rather want to continue the conversation this way, I am okay with that.  We just need to study more about Agents.  The case over here is kind of unique, as we see it today with our knowledge.  The way we found to retrieve the agents was using AC Rules, because some of our Tasks are not to have all Managers in all the Org. Units as Possible Agents.   Each WFs we created is for a specific Org. Unit to deal with, and each one has only one Manager, therefore there are not other Possible Agents that apply.  One Org. Unit is HR, the other one Finance, etc.    

      That is an example from cases that requires a Manager as Agent. 

      Also, if we manually place the specific HR Object in the Agents piece of each Task, as we manually created our Org. Chart for Change Management as a subset of the big one that holds all the corporation employees, we do not necessarily will have a match between same Org. Units and Positions in all our Sol Man Landscape.   In that sense, as we transport things to Production and if the Org. Chart is different there, we may have to manually have to update the Agent information on the target system, every time.  We may be able to match the Org. Chart, that is the ideal as we are not live, yet.

      As written in the blog, we are learning about SAP WF and there is always room for improvement to make things easier for all.  I reiterate the gratitude for sharing and challenging us.  If we can improve what was written and you have the time and disposition to assist, we are more than pleased to work with you.

      Thanks,

      Juan

      (0) 

Leave a Reply