Problem: A table of Workflow Objects (ABAP OO) to be passed as parameter (importing / returning)

Fri May 8 11:36:59 EDT 2015

Hi Florin,

No, instances aren't "officially" kept alive during persistency state
conversion, but if you buffer them then they remain in memory for some
time. If an RFC steps in then all becomes lost. In case of instance events
it may work as they are usually processed in the same context - I haven't
tried it.

Or to explain it another way, if your class instance is properly buffered,
then switching to persistent LPOR and back will simply find the old
instance again and still have the values intact. Yes it does work, I've
done it :-)

Risks are if there is an RFC call all is lost. If there is an interruption
all is lost (no errors allowed!).

Regards,
Mike

On Mon, May 4, 2015 1:59 pm, Florin Wach wrote:
> Hi Mike,
>
>
> well yes ... and no ... I'm currently using a workaround by calling the
> functional method through a background tasks, which is working fine.
>
> Nevertheless the list of objects doesn't work with a container-like
> function-method.
>
>
> I don't know, where you get it from, that the events are processed
> synchronously, keeping the instances alive without going through the
> persistency
> interface, because the SWW_WI_START_VIA_EVENT_IBF is transfers the event
> container through the XML-container, which has turned the instances
> through the
> LPOR-interfac, making them SIBLFPORB's (with B).
>
>
>>From there, the instances are picked up again and made unpersistent
>> again, using
> a separate task. ... And the tRFC is always used on event processing, in
> order
> to change the user-context to WF-BATCH.
>
>
> But aside from this, a parameter for a method call cannot hold currently a
> list
> of objects, regardless of how you specifiy them, and yes, ... the list is
> context-wise created, so I don't want to store them away just for a
> single-shot
> :-)
>
>
> Thx for addressing that again, ... and there's no time here to create
> OSS-Messages, but maybe someone from the group likes to have some fun,
> chatting
> with the SAP Support about it :-)
>
>
> Mit freundlichen Gruessen / With kind regards
> Florin Wach
> Senior Workflow Engineer
> SAP Certified Development Associate for Workflow
>
> ------------------------------ --------------------
> http: //www. systems-integration. net
>
>>
>>     Mike Pokraka <wug at workflowconnections.com> hat am 4. Mai 2015 um
>> 14:11
>> geschrieben:
>>
>>
>>     Hi Florin,
>>
>>     Sorry about late reply, you've probably solved this by now, but...
>>
>>     OK, I wasn't aware that this was in an event binding. However it may
>> still
>>     work, as most instance linkage events are processed synchronously -
>> this
>>     is why your table of ref-to's works. I suspect it may break down
>> under
>>     heavy load when the system decides to shift stuff into TRFC.
>>
>>     I would debug the error message too, and possibly raise it with OSS.
>> This
>>     should normally work, and the table approach as you have it would be
>> my
>>     choice too for an instance linkage.
>>
>>     Of course, persisting a collection object is also easy if the data
>> already
>>     exists in the DB. An order header is basically a collection of
>> items, so
>>     the sam logic may apply? If on the other hand the data is completely
>>     transient (e.g. something a user has just hilighted in a dialog),
>> then
>>     it's probably overkill to write that to the DB.
>>
>>     Regards,
>>     Mike
>>
>>
>>     On Sun, April 26, 2015 9:14 pm, Florin Wach (SI) wrote:
>>     > Hi Mike,
>>     >
>>     > nice to hear from you again :-))))
>>     >
>>     >
>>     > Well, those objects Ã¢â‚¬Â¦ they come in as an event parameter for
>> a wait
>>     > step, so thereÃ¢â‚¬â„¢s some persistency in-between.
>>     >
>>     > Ã¢â‚¬Â¦ I didnÃ¢â‚¬â„¢t mean to create a persistency interface for
>> a collection
>>     > on
>>     > that time :-) Ã¢â‚¬Â¦ or do you have a more simple idea on that,
>> too?
>>     >
>>     > Plan-B is, to create a background step instead of the container
>>     > operation.
>>     > ThatÃ¢â‚¬â„¢ll work without refactoring on the current solution,
>> too much.
>>     >
>>     >
>>     > With the very best wishes
>>     > Florin
>>     >
>>     >
>>     >
>>     > Mit freundlichen GrÃƒÂ¼ÃƒÅ¸en / With best regards
>>     > Florin Wach
>>     > Senior Workflow Engineer
>>     > Systems-Integration
>>     >
>>     > ----------------------------------------------------------------------
>>     > www.systems-integration.net <http://www.systems-integration.net/>
>>     >> Am 23.04.2015 um 15:29 schrieb Mike Pokraka
>>     >> <wug at workflowconnections.com>:
>>     >>
>>     >> Hi Florin,
>>     >>
>>     >> Why not use a collection object to hold the instances? Standard
>> OO
>>     >> pattern to do that sort of thing...
>>     >>
>>     >> Regards,
>>     >> Mike
>>     >>
>>     >> On 23 Apr 2015, at 12:52, Florin Wach
>>     >> <florin.wach at systems-integration.net
>>     >> <mailto:florin.wach at systems-integration.net>> wrote:
>>     >>
>>     >> Dear wuggies,
>>     >>
>>     >>
>>     >>
>>     >> I'm somehwat stuck with a problem that didn't seem to any issue
>> at all:
>>     >>
>>     >>
>>     >>
>>     >> I've a container elemente based an an ABAP Class, having checked
>>     >> "Multiline" on.
>>     >>
>>     >> This is working fine, and I'm using this list in the event type
>>     >> coupling
>>     >> and in other steps.
>>     >>
>>     >>
>>     >>
>>     >> Now, when I'm defining a container operation, where one of the
>> import
>>     >> elements is a table of those class instances, i receive the error
>>     >> "Invalid value for parameter 'xyz' (method ... )".
>>     >>
>>     >>
>>     >>
>>     >> I doesn't work, when I declare the parameter as a table-type OF
>> class,
>>     >> nor does it work, declaring the type SIBFLPORT (which is the
>> table-type
>>     >> for SIBFLPOR).
>>     >>
>>     >>
>>     >>
>>     >>
>>     >>
>>     >> I got another method, which is using the Table-Typ of type-ref-to
>> and
>>     >> which is called by a WORKITEM. And that works. There're no error
>> given
>>     >> that the type mismatches or ...
>>     >>
>>     >>
>>     >>
>>     >> What's wrong with it?
>>     >>
>>     >>
>>     >>
>>     >> Florin
>>     >>
>>     >> _______________________________________________
>>     >> SAP-WUG mailing list
>>     >> SAP-WUG at mit.edu <mailto:SAP-WUG at mit.edu>
>>     >> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>     >> <http://mailman.mit.edu/mailman/listinfo/sap-wug>
>>     >> _______________________________________________
>>     >> SAP-WUG mailing list
>>     >> SAP-WUG at mit.edu
>>     >> http://mailman.mit.edu/mailman/listinfo/sap-wug
>>     >
>>     > _______________________________________________
>>     > SAP-WUG mailing list
>>     > SAP-WUG at mit.edu
>>     > http://mailman.mit.edu/mailman/listinfo/sap-wug
>>     >
>>
>>     _______________________________________________
>>     SAP-WUG mailing list
>>     SAP-WUG at mit.edu
>>     http://mailman.mit.edu/mailman/listinfo/sap-wug
>>_______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
>