Delegation / Recursion fails on PERSDATA

['Mark Pyc']

Thanks for this hints Jocelyn, but no luck this time. The refresh didn't
help and thankfully I'm not subject to Structural Auths. To be fair I'd
been giving some misleading information - a case of digging too deep and
getting dirt in my eyes.
 
The reason that the testing worked in SWO1 and not in the Work Item was in
fact due to the Delegation. Foolishly I was testing ZPERSDATA in SWO1 and
the Work Item was using PERSDATA. Testing PERSDATA in SWO1 also fails to
work! Therefore, the delegation is part of this issue. Having discovered
this I modified the code to remove the use of the Function Module and
bring everything back into the Object (just to check I hadn't been making
the same testing mistake all along) however it didn't work.
 
THE BODGY SOLUTION:
The bodgy solution therefore required two parts. I did need to extract the
call to the method into a Function Module to get a clean block of memory.
I also needed to use the Subtype (Z) in expression references in the task
(can be done by either raising the event on the Subtype (avoiding
Delegation completely) or instanciating a reference to the Subtype).
 
Some of the many things that make me go Hmmmm...
 
Even when called from the subtyped object, the function module variables
for the current and previous instance contain the same Object Handle when
viewed in debug. However, when the call to SWC_GET_PROPERTY is made, the
correct object is called! This is the difference between the Subtype and
the Delegated parent.
To see the same Handle returned by the method made me wonder how the
Subtype managed to call the correct instance. Just for fun I converted the
container returned by the method to Persistent and back to Runtime before
calling SWC_GET_PROPERTY and this broke what was magically working.
 
A call in ZPERSDATA "SWC_CALL_METHOD SELF 'FindPredecessor' L_CONT."
overwrites the value of OBJECT-KEY with the key of the predecessor
instance!?!? All other attributes seem remain to remain unaffected by this
corruption. This led me to believe the function module would help, which
it did.
 
I don't really expect to get answers to these queries, but since I wasted
so much time developing questions when really looking for answers, I
thought I'd share these little insights...
 
Have fun!!
Mark
 
 
 
 
 
 
 
"Dart, Jocelyn" <jocelyn.dart at sap.com>
Sent by: SAP Workflow <Owner-SAP-WUG at MITVMA.MIT.EDU>
23/03/2004 04:22
Please respond to SAP Workflow Users' Group
 
 
        To:     SAP-WUG at MITVMA.MIT.EDU
        cc:
        Subject:        Re: Object recursion (of sorts) fails on PERSDATA
 
 
Hi Mark,
Have you tried using macro SWC_REFRESH_OBJECT
to make sure it is recalculating the attributes correctly?
 
Also watch that you aren't being hit by HR structural authorisations
 - you need to make sure this is being dragged out in background by
WF-BATCH
with the "advance in dialog" flag off.
Jocelyn
 
-----Original Message-----
From: SAP Workflow [mailto:Owner-SAP-WUG at MITVMA.MIT.EDU] On Behalf Of
'Mark Pyc'
Sent: Tuesday,23 March 2004 12:44 AM
To: SAP-WUG at MITVMA.MIT.EDU
Subject: Object recursion (of sorts) fails on PERSDATA
 
 
G'day WFers,
 
Disclaimer: My HR knowledge is limited - there may be a simple solution.
Release: Enterprise 620
 
I have a requirement to build a notification in HR when a user changes
their name through ESS. This message should include the following:
"This is to notify you that employee Staff no &P0002-PERNR& from
&P0001-ORGEH& has changed their name from {Previous ANRED Previous VORNA
Previous NACHN} to &P0002-ANRED& &P0002-VORNA& &P0002-NACHN&. Please amend
your records
accordingly."
 
To set this up I have used subtyped object PERSDATA. When I tested the
method 'FindPredecessor' in SWO1 it returned what I wanted. I then set up
virtual attributes for the pervious Form Of Address, First Name and Last
Name and in the implementation I tried initially to use a call to SELF for
the method.  When I tested the new attributes they were the same as the
current instance!?!?!
 
Debugging showed that the object reference returned by the method was the
same as the current object - D'oh!. Assuming this was a case of the BOR
not being real OO and failing to handle recursion (suspect incorrect use
of global memory variables) I took the code out of the method directly and
wrapped it in a function module (in an effort to get a new memory
allocation and prevent overwrite of global variables). This code is
included here for reference:
 
FUNCTION ZHR_PERSDATA_PREVIOUS2.
*"--------------------------------------------------------------------
*"*"Local interface:
*"       IMPORTING
*"             REFERENCE(I_OBJKEY) TYPE  SWOTOBJID-OBJKEY
*"       EXPORTING
*"             REFERENCE(O_FOA) TYPE  Q0002-ANREX
*"             REFERENCE(O_FIRSTNAME) TYPE  P0002-VORNA
*"             REFERENCE(O_LASTNAME) TYPE  P0002-NACHN
*"--------------------------------------------------------------------
  DATA:
    O_CURR TYPE SWC_OBJECT,
    O_PREV TYPE SWC_OBJECT,
    PREV_KEY TYPE SWOTOBJID-OBJKEY.
 
  SWC_CONTAINER L_CONT.
  SWC_CREATE_CONTAINER L_CONT.
 
** Instanciate Current Object
  SWC_CREATE_OBJECT O_CURR 'PERSDATA' I_OBJKEY.
 
** Determine Previous Instance
  SWC_CALL_METHOD O_CURR 'FindPredecessor' L_CONT.
  SWC_GET_ELEMENT L_CONT 'SingleObject' O_PREV.
 
** Retrieve Relevant Properties
  SWC_GET_PROPERTY O_PREV 'FormOfAddress' O_FOA.
  SWC_GET_PROPERTY O_PREV 'FirstName' O_FIRSTNAME.
  SWC_GET_PROPERTY O_PREV 'LastName' O_LASTNAME.
 
ENDFUNCTION.
 
Testing this in SWO1 now worked - proof of sorts that I was on the right
track. The real bummer is that when I now use this object in a workflow
the workitem text behaves as in the initial case - the "previous object"
reference returned is the same as the current and so the message says
"Employee has changed their name from NEW NAME to NEW NAME". When I
display the Work item, view the container and expand the object it has the
correct values for these attributes!?!?!
 
This is not a case of buffer refresh or incorrect expression references in
the task text.
 
I suspect if I used a method to return the variables it may work, but I
really need these values as attributes so they can be included in a Start
Condition. I realise I can code the read of these attributes myself rather
than using the SELF method call, but I'd really like it to work the way I
think it should.
 
Has anyone suffered a similar plight before??
 
Many thanks for any tips.
 
Have fun,
Mark