Magically Encapsulated ABAP Objects in WorkFlow

[Dart, Jocelyn]

Mike, 
As always workflow uses the object instance reference held in your workflow container element to call the class to get the Local Persistent Object Reference.  That is your class is supposed to provide a persistent object reference.  
 
Whenever workflow needs to use some attribute or method of the class is uses the object instance reference to call the class at that time - e.g. when building the text of a work item, when a user executes a work item from an inbox, etc.  
 
For the sake of performance it would not be sensible to hold all instantiated objects with the workflow, as workflows can extend over days/weeks/years and across that time of course the underlying persistent data often changes.  Workflow does NOT hold the entire object instance in memory and never did.  Not even in BOR object days.
 
As per the examples in the SDN blogs, your class constructor should derive the relevant information from the database to provide persistant values for the instance attributes. 
 
And of course if all you wanted was a counter, you would usually be better off using a container element and container operations anyway rather than encapsulating it in a class. 
 
Regards,
Jocelyn 
 
 

________________________________

From: sap-wug-bounces at mit.edu on behalf of Michael McInerney
Sent: Tue 7/04/2009 4:28 AM
To: SAP Workflow Users' Group
Subject: [LIKELY JUNK]Magically Encapsulated ABAP Objects in WorkFlow 



 Perhaps I was naïve 

 

Given I have set up a usual ABAP class ZCL_WIDGET, and implemented simple IF_WORKFLOW Interface  methods LPOR and FIND_BY_LPOR Methods, 

 

I can

 

Create a variable "LO_WIDGET"  in the workflow container as type CL ZCL_WIDGET

 

Run a task  that runs a ZCL_WIDGET.CREATEINSTANCE method (as in Jocelyn's Blog) that populates this variable in the wf container  ,

 

(for future discussion, the ZCL_WIDGET class has an attribute named COUNTER, which is initialized to 0 upon instantiation.)

 

This works.

 

At this point, I thought I would magically have a fully encapsulated (ie with data) object to use throughout the rest of the workflow.

 

I thought I could then set up another task which runs the CL ZCL_WIDFGET increment_Counter method

 

Then, I thought, if I bound  LO_WIDGET into and out of WI_OBJID of a task implementing the INCREMENT_COUNTER method, I expected to wind up with LO_WIDGET in the workflow container with a COUTER ATTRIBUTE whose value was 1

 

This does not work for me (in this simple form)  - is it intended to  (I'm beginning to think its not)?

 

Or will I have to set up a persitant widget class and change the find_by_lpor to first get_persitant else create_persitant  (which will take som eof the magic out of it)?  

 

Thanks...

 

...Mike

 

Mike McInerney - Duke University - (919)684-5371