Is there a way to access ABAP OO instances from a batch job report

[Former Member]

Hello,

I am looking for a way to access ABAP OO instances from a batch job report. My circumstances are the following:

I have got some ABAP OO coding that identifies other objects (class instances) that have to be processed (they have a DoIt method that does some calculation). As this processing is time consuming and performace relevant I have to parallelize this in batch jobs. This batch jobs however can only be "simple" ABAP reports according to SM36. The problem is now that I dont really know how to tell the batch job report what objects to process. Somehow I have to access theses instances from that batch job report.

Does anybody have an idea?

Greetings

Matthias

[Former Member]

Hello Matthias,

if you are working on a NetWeaver 7 system, shared objects might solve your requirement. You can have something like a preparation program which determines the objects to be processed and saves the object instances in the shared memory. Your batch jobs can access the shared memory and execute the processing logic. You only have to implement a locking functionality to avoid that two parallel jobs try to process the same object instance. I am not an expert to shared objects, but I think the framework even provides some functionality for protecting objects against multiple accesses.

For further information refer to the [shared objects online help page|http://help.sap.com/saphelp_nw70/helpdata/en/c5/85634e53d422409f0975aa9a551297/frameset.htm].

Hope this helps,

David

[Former Member]

Hi David,

thanks a lot for your help. After a lot of searching on the net this seems to be the only way to cope with it. However I am not sure about the locking mechanisms and if its suitable for mass data processing. In the help page you suggested the following is stated which I do not fully understand::

-

-

---

"The current lock logic does not enable you to set specific locks for the following requirements:

· Many parallel read and write accesses

· Frequent write accesses

· Division into changeable and non-changeable areas

Although the lock logic makes the first two points technically possible, they are not practical because most accesses would be rejected."

-

-

---

Does this mean

a) if I dont want to set "specific locks" for frequent write accessess I am fine

or

b) I am discouraged from use shared memory technics for frequent write accessess?

In the latter case I will have a problem...

What do you think?

Greets

Matthias

[Former Member]

Hello Matthias,

the shared objects concept is recommended when you have just a few write accesses. It is explicitly discouraged from using it with many parallel read/write accesses. If shared objects might help you with your requirement depends on the number of object instances you need to process and the processing time for each object. Both factors determine the number of read / write accesses. Another point to consider is if the data is really shared by the parallel jobs or if each job has its own workload.

An alternative is to do it in the "classical" way: You can share the data between parallel programs through a database table. The persistency framework helps you to store the object instances in the database and to retrieve them afterwards. For the record locking, you can create lock objects.

Hope this helps,

David

[Former Member]

Hi David,

thanks for your answer. This already helps me a lot. One last comment regarding shared objects:

I have about 3-50 class instances that sholud be accessible to batch job reports. Each job handles one of these class instances. They all have a DoIt method that massively accesses and changes database tables. Each of these instances i.e. each job is reading from one or more DDIC tables and writes to only one separate DDIC table. This means each job has its own workload. No parallel write accesses to the same table. According to what you say this means nevertheless: Using shared objects is discouraged in my case, would you agree?

You propose the use of the "classical way" which is new to me... Share data between reports by using database tables even for class instances. Can you recommend some good docs to learn how to use the persistency framework?

Thx in advance.

Matthias

[Former Member]

Hello Matthias,

yes, in this case I don't see the reason to choose shared objects. Persistent objects will solve your requirement as well.

First place to check for information is the [SAP Online Help page for Object Services|http://help.sap.com/saphelp_nw70/helpdata/en/ab/9d0a3ad259cd58e10000000a11402f/content.htm].

Afterwards, the following [blog|/people/thomas.jung3/blog/2004/12/08/abap-persistent-classes-coding-without-sql] and [eLearning session|https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/media/uuid/705398b3-599e-2a10-9f88-eb5353e8b860] from Thomas Jung are recommendable.

Additional information is surely available in the SDN

Best regards,

David

[Former Member]

Hi David,

ok, thanks a lot once more. I think this is the most proposing way and thus I gonna go this way.

Greets

Matthias