Persistent objects : a good idea?

[dhorions]

Hello,

I was looking into the <a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/ab/9d0a3ad259cd58e10000000a11402f/frameset.htm">Persistent objects</a> in ABAP and was wondering if anyone has used this in a production environment.

How is the performance?

How do you implement it for a more complex relational database structure?

If anyone knows where I can find more information, I would be glad to hear it.

Thanks in advance,

Dries

[marcelo_ramos]

Hi,

<b>Look at these links:</b>

<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/840ad679-0601-0010-cd8e-9989fd650822#q-20">Object Services Example</a>

<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/f2dac69e-0e01-0010-e2b6-81c1e8e5ce50">Best Practices</a>

<a href="https://www.sdn.sap.comhttp://www.sdn.sap.comhttp://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/c1be1003-0701-0010-3795-f87160de6483">NetWeaver Developer’s Guide</a>

<b>

You can look for Share Memory Enable:</b>

<a href="https://wiki.sdn.sap.com/wiki/display/ABAP/ABAPObjectsShareMemoryEnable+%28SHMA%29">Share Memory Enable</a>

<a href="https://www.sdn.sap.com/irj/sdn/wiki?path=/display/profile/2007/05/04/storingandaccessingtheinternaltablevaluesinSharedMemoryArea.&">Shared Memory Area - Wiki Example</a>

<a href="http://help.sap.com/saphelp_nw2004s/helpdata/en/c5/85634e53d422409f0975aa9a551297/frameset.htm">SHMA Help</a>

<b>

<b>Don't forget to close this Thread and reward points when your question be answered.</b>

Regards.

Marcelo Ramos

[Former Member]

I think you have to be VERY careful in moving on this.

I can see the point of some persistence for example say you have a sales order class you could usefully use this without having to "re-calculate" all the attributes etc every time you "re-instantiate" the object (sales order).

However as SAP persistent objects don't have any locking mechanisms (yet) and data base updates need to be "committed" there seems to me a lot of scope here for creating "duplicate"or redundant data which is certainly NOT what you want to have in a productive system.

In any case if you store the same data in more than one place you are likely to get corrupt / missing / inconsistent data so with current SAP methodology this could be a real pronblem.

There is certainly some merit in the idea of encapsulating the data ("attributes") within an instance of a class and storing it somewhere but this needs to be implemented VERY CAREFULLY. Bare in mind also that depending on the complexity of the class and the number of instances you want to save your data storage requirements will dramatically increase.

SAP was essentially designed on a "Relational Data base" system where everything was mainatined in sets of linked tables - For example you'd have the sales order base data in a sales order table (VBAK/VBAP etc). Business partners would be pointed to by a field in VBAK and stored in another set of tables.

Similarly deliveries and schedule lines for the order would be held in yet another set of tables.

Now a real sales order class would contain ALL this information in a single object. However trying to encapsulate all this data into instances of the sales order and maintain consistency with Standard SAP so that "Normal transactions" such as VA01 - create sales order would still work properly would IMO be well nigh impossible without maintaining 2 distinct sets of data.

The entire SAP system would essentially have to be re-designed to really provide for useful persistent classes -in theory an excellent idea but we are some ways off this yet.

So the answer to your question I'm afraid is a vague

Yes - possibly

No - possibly

Maybe - possibly.

Cheers

Jimbo

[dhorions]

I guess i'll wait untill this is more mature.