IPA - In LTM lookup agents linked to actor by actorid

 1 Replies
 1 Subscribed to this topic
 52 Subscribed to this forum
Sort:
Author
Messages
timbomom
Advanced Member
Posts: 28
Advanced Member

    In IPA, I can't find a way to look up the agent linked to an actor.  I want to look for the agent by searching on actor id (userid). 

     

    Thanks,

    Patricia

    Woozy
    Veteran Member
    Posts: 709
    Veteran Member

      Hi Patricia,

      Just for clarification, what do you mean by "agent" and what exactly are you wanting to do?  In my (TM) world I think of "agent" as the link between the actor and the employee, so I want to be sure we're on the same page.  The issue is that there can be are multiple agents for each actor record.

      The easiest way I've found to do this is with SQL, doing something like this (DB2 SQL):

      select
              emp.employee
      from
              lmhcm.parentagent as pa
              inner join lmhcm.agent as a
                      on a.parentagent = pa.parentagent
                      and a.borbusinessclassname = 'Employee'
                      and hex(a.deleteflag) = repeat('0',32)
              inner join lmhcm.employee as emp
                      on emp.uniqueid = a.borbusinessobjectkey
      where
              pa.actor = 'source actorID'

      Note that none of these are in GEN, so you can't join directly to Actor (unless your db is set up differently from ours).

       

      I've never figured out how to duplicate this approach using Landmark queries.  The only way I've been able to do this with IPA (other than SQL) is to do a filter on the destination business class (Employee in our case) like this:

      _dataArea="prodhcm" & _module="hr" & _objectName="Employee" & _actionName="Find" & _actionOperator="NONE" & _actionType="MultipleRecordQuery" & _runAsUser="" & _pageSize="30" & _filterString="AgentEmployee=\"source actorID\"" & _relationName="" & _setName="" & _asOfDate="" & _effectiveDate="" & HROrganization & Employee

      The only problem with this approach is that it is VERY SLOW and sucks lots of resources (CPU) when it is running.  In our environment where we have 30,000 records in the employee business class, it can take 3-5 minutes (!) for the query to complete, and it sucks 50% of a CPU.  For this reason, we almost always use SQL when we need to do this.

      I'd love to have a better approach if anyone has one to share.

      Good Luck!

      Kelly

      Kelly Meade
      J. R. Simplot Company
      Boise, ID