Problem: A table of Workflow Objects (ABAP OO) to be passed as parameter (importing / returning)
Florin Wach (SI)
florin.wach at systems-integration.net
Fri May 8 11:58:25 EDT 2015
Hi Mike,
that's a very interesting aspect with that buffering... and yes, I do buffer the classes with a Singleton on Class-level. Is there another approach?
Thanks for the details, and I'll keep checking on that. :-)
Best wishes
Florin
> Am 08.05.2015 um 17:36 schrieb Mike Pokraka <wug at workflowconnections.com>:
>
> 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
>
> _______________________________________________
> SAP-WUG mailing list
> SAP-WUG at mit.edu
> http://mailman.mit.edu/mailman/listinfo/sap-wug
More information about the SAP-WUG
mailing list