Class attribute in technical workflow log not updated

Question

Hi Gurus,
I built a workflow analogous to the famous demo workflow "demoformabs" but with the demo class: CL_SWF_FORMABSENC instead of the BOR: FORMABSENC.
In the BOR Formabsenc there is also an attribute for the "Approver" (USR01) in addition to "Creator" (USR01).
This attribute "Approver" is missing in the class "CL_SWF_FORMABSENC".
So I added this attribute "Approver" also in the class "CL_SWF_FORMABSENC":
data APPROVER type SIBFLPORB value CL_SWF_BOR_TYPES=>MC_USR01.
Finally in the method "approve" I set the value for the attribute "APPROVER".
me->approver-instid = me->APPROVBY.
I can see that the value has been successfully set by setting a binding from this class attribute to a workflow container element.
BUT, in the technical workflow log (container) I can not see the class attribute "Approver" populated.
Here it´s still displayed as < no instance >.
What do I need to do, to make this value appear also in this class attribute in the technical workflow log?
Albeit I know, that it´s working, I am getting confused, that it´s still displayed as empty.
Cheers,
Dominik

Answer 1

Hi Dominik,
You should not populate attributes in this manner, for the very reason you're experiencing. Attributes are transient and behave like variables, i.e. when the class stops existing they disappear. During binding only the key is transferred, and - if needed - the class is re-instantiated at the other end. If you have implemented some kind of buffering/instance management (not a bad idea), then you may be lucky to have attributes survive if everything happens within the same program context. However once your WF session stops executing, this is lost.
This is why when you look at the log later, it is re-instantiating a completely new instance - where would it know the approver from?
The attribute value must be written to the DB somewhere, so that any later object instantiation (e.g. when you look at the log) will read the value and populate the attributes correctly.
Incidentally this is why OO theory discourages the use of public attributes and suggests GET_ and SET_ methods instead....
Regards,
Mike