SAP CRM: Making sense of Org Model evaluation paths

I've recently faced the requirement to retrieve the BP in the manager role (head) of an orgs parent org. In CRM, you can use function module RH_STRUC_GET to do just that: Supply it with a starting point (BP, central person, position or org unit) and it will do its work according to the evaluation path given.

Checking what had been implemented before in our system, I noticed  that those implementations did not fully leverage evaluation paths but rather called the function modules themselves (i.e. they'd have a user, then they would get the  central person for that user, then they'd get the positions for the central persons). This can all be done without development and simple customizing. Here are the steps:

1. Create a new evaluation path in customizing in SM30, table T778A
   
2. Maintain the properties, i.e. the actual evaluation path
   
   There's a great introductory blog on SCN, but I found it way too technical to get a basic understanding of how evaluation paths work. So here are the options explained in a nutshell (to the extent that I understand them):
   1. The lines are not sequential steps. So each line is its own path, in a way. It adds its results to the pool of results and each line processes the results of the previous line. Example: RH_STRUC_GET is started with org ID 20 and a depth of 3. Line 10 above will therefore determine the preceding org of org 20, say org 19 and - since depth is 3 - perform two more iterations (i.e. preceding org of 19, say 18, and preceding org of 18, say 17). All these orgs are added to the result pool. So when line 20 is reached, it will determine the managed by for all entries in the pool (i.e. for orgs 20, 19, 18 and 17) and add them to the pool.  When line 30 is reached it will determine the holders/central persons of all the managed for positions identified by line 20. And line 40 will eventually determine the business partners for those central persons.
   2. Obj. Type is the source object type (e.g. Org Unit, Position, Central Person) and rel. obj.  type is the target (which we are looking for).
   3. A/B does not mean "upper" or "lower" object, as seen in the org model. Rather, it refers to the relationship used. So for instance, lines 20 and 30 go from org unit to position and from position to CP. This would be "moving down" if looking at the org structure. Yet, line 20 is "B" because it uses relationship 012. 012 is usually "Manages", so would go from the position to the org unit it manages. However, we're going the opposite way, i.e. from the org unit to the position, so we are looking for the inverse/passive result of this relationship. This is why we enter "B" and this changes the relationship name from "Manages" to "Is managed by ".
   4. Priority can be ignored/left at *. There's an F4 help, but I could not really figure out what it does.
   5. Skip refers to output only. As you can see from point 1, the output can contain quite a lot of results, especially the more entries you have in your path. Skip allows you to exclude the results from this line from the output of the evaluation. This affects display only. The line will still be executed and the results from all non-skipped lines will remain the same. So skip all lines which you do not need to process in your own logic.
3. Execute function module RH_STRUC_GET. This is quite straight-forward:
      
   1. OTYPE and OBJID define your starting point, in this case an org unit
   2. WEGID (German for Path ID) is the new evaluation path you just created
   3. TDEPTH refers to the number of steps the evaluation performs. I've chosen 5 because I want to go from source object (1) to parent object (2), from parent object to position (3), from position to central person (4), from central person to BP (5). Note that a lot more results will be added to the result. So for line 10 alone, depth 5 would mean that the result contains the source object (1), the parent (2), the parent's parent (3), the parent of that one (4) and the parent of that one (5). And line 20 would add (let's just take the example of "parent's parent" (3)) the parent's parent's managing position (4)  and the central person of that position (5) - but not the BP as depth is only 5. I think you get the idea. The result will contain far more data than what you're looking for. But I'll explain later how to make sense of the result.
   4. TFLAG: Adds texts (object descriptions) to the result. Disabling increases performance.
   5. VFLAG: Have not completely understood this one. There's a FM documentation which explains this, if you want to make sense of it.
   6. AUTHORITY_CHECK: Only accesses objects for which user has authority.
4. Process the result. What you need for this depends on your requirement, but the following tables are filled:
       
   1. RESULT_TAB: Provides a list of all found objects
      
   2. RESULT_OBJEC: Like RESULT_TAB but with more information (I've excluded text when running it, it would normally be filled):
      
   3. RESULT_STRUC: This can be used to exactly retrace how the org structure was evaluated. I'll give an example for my requirement above:
      
      First, let me describe the fields:
      1. SEQNR: The key field for this table and the order in which the result list was determined
      2. LEVEL: Corresponds to the depth, i.e. how many steps did it take to get here from the source object (where source object is level 1). Look at my example regarding depth above to better understand this.
      3. OT, OBJID: The result object (can be used to match the other two tables)
      4. PDOWN: SEQNR of child element (remember what I said above, this does not refer to parent/child in the org structure but to parent/child according to the relationship)
      5. VCOUNT: I believe this is the number of elements on the same level. Not sure, I don't use it.
      6. PNEXT: SEQNR of next element on the same level
      7. PPREV: SEQNR of previous element on the same level
      8. PUP: opposite of PDOWN, i.e. provides SEQNR of parent element

So how do I fulfil my requirement using this table?

1. SEQNR 1 is my starting point, PDOWN is the parent element (remember this is DOWN because the relationship goes from A to B, even tough I'm actually going "up" in the org structure), SEQNR 2.
2. SEQNR 2 is my parent element. From here I need to get to the managing position. It's the entry that fulfils the following conditions:
   1. It's on Level 3 (LEVEL = 3)
   2. It's a position (OT = S)
   3. It's upper node is the org in SEQNR 2 (PUP = 2)
   4. This gives me lines 6 and 7
3. At this stage, I will have to include some custom logic and query the attributes of the positions (e.g. by using CL_CRM_ORGMAN_INTERFACE=>READ_ATTRIBUTES_SINGLE). Let's say that line 7 is the right one.
4. Now I need the central persons for this position. They fulfil the following conditions:
   1. OT = CP (Central Person)
   2. PUP = 7 (parent node is SEQNR 7)
   3. This his gives me line SEQNR 25 (but it could be more than one line that fulfils this as multiple partners can be assigned to a position)
5. Lastly, I need the business partners for those positions. They will fulfil the following conditions:
   1. OT = BP (Business Partner) 
   2. PUP = the SEQNR of the lines in the previous step.
   3. For SEQNR 25, this gives me SEQNR 44.

So BP 7000000951 is (one of) the manager(s) of the parent org unit.

So with a bit of customizing, one function module call and pretty straight forward evaluation of the result I have been able to fulfil my requirement.

Evaluation paths are a bit difficult to understand, but they allow you to greatly reduce the need for custom development so your code becomes leaner and easier to maintain.