Update persistent objects (Like JDO in JAVA) with SAP Data Integrity

[Former Member]

Hi all

Since reading the post on Persistent Objects I've been looking at this a little more closely.

In the JAVA model SAP has implemented JDO (Java Data Objects) as a data store which maintains data integrity with "Relational Data Bases". I.E the relevant SAP tables are updated automatically.

For example you can retrieve say an Employee, change the persistent fields such as salary and then send it back to the data store.

The JDO runtime automatically tracks changes on persistent objects and transparently sends the updates back to the data store at commit time.

( For some of our JAVA colleagues

private void raiseSalary(int empId, double percent) {

PersistenceManager pm = null;

try {

pm = pmf.getPersistenceManager();

Transaction tx = pm.currentTransaction();

tx.begin();

Employee emp = (Employee)pm.getObjectById(new Employee.Id(empId), false);

double oldSalary = emp.getSalary();

double newSalary = oldSalary + percent * oldSalary;

emp.setSalary(newSalary);

tx.commit();

}

finally {

if (pm != null && !pm.isClosed())

pm.close();

}

}

)

The method raiseSalary() raises the salary of an employee by a given percentage. First, the employee is retrieved from the database with the getObjectById() method. Then the new salary is computed from the old one. The salary of the employee is changed by calling the method setSalary() on the employee with the new salary as the parameter. When the transaction is committed (tx.commit()), the update is sent to the database.

Now in ABAP I don't actually see anywhere how to link any change in the persistent object to the relevant SAP tables. For example if I use the similar example as above to raise an employee's salary I can't see anywhere where the relevant infotype gets updated.

The Idea of persistent objects the more I think about it is great but how exactly to do this in ABAP whilst maintaining data integrity seems to be a problem --or have I missed something here.

BTW if you have access to J2EE / Java machine the JDO works great.

Maybe a time to switch from ABAP for this type of processing.

Cheers

jimbo

[Former Member]

The last biggish ABAP development I worked on took exactly this approach, encapsulating all the database accesses within one class which then had various methods for the different actions you might want to take, e.g. "add_ line", "void_line" "post_reversal" etc etc... the logic in the class also took care of change history, referential integrity etc. The calling programs ended up with no direct database table access at all because our design assumed that the ABAP front-end might one day be replaced by an external {non-SAP} Java system.

In other words, you can build the equivalent to the JDO you described inside an ABAP object, but obviously SAP themselves have not yet provided this for their tables - it would require a re-write of some of the core modules functionality, with some of that logic going back 20+ years.

[Former Member]

This was rather a point to be thrown open for discussion rather than a specific question

[GrahamRobbo]

Hi Jimbo,

you got me thinking because I was sure I knew how all this works - but now I'm not so sure ...but I am still thinking.

Anyway, continuing my thinking out loud....(and stealing phrases from SAP HELP and Thomas and Rich's book "Next Generation ABAP Developement")...and by no means pretending to be an expert at this...

1. Persistent Objects are designed to abstract the underlying relational database table(s) from the developer by hiding SQL and providing getter and setter methods to manipulate the data. Persistent objects are generated from the data dictionary and therefore have a one-to-one relationship with the underlying database objects.

2. A Business Object will almost certainly need to be persisted across several Persistent Objects (i.e. db tables) in a way that maintains it's integrity. Therefore it makes sense to build a further layer of abstraction above the Persistence Layer called the Business Object Layer. Here we create a global class for each Business Object that provides the CRUD (Create, Read, Update, Delete) methods for the Business Object. These methods hide the persistence layer from the developer, so no not only does the developer not need to know anything about SQL he also no longer needs to call the getter and setter methods of the Persistence Layer. A single Business Object may have to manage quite complex relationships between many persistent objects.

3. A business process will almost certainly need to touch several different types of Business Objects in a way that maintains integrity. Therefore it makes sense to build a further layer of abstraction above the Business Object Layer called the Model Layer. The Model classes implement the business logic of the application and are not limited to manipulating a single business object type. This is the level that would most need to implement transaction processing as a single business transaction may well "touch" multiple business objects and business object types. In the new world of ESOA the "source of data" could change from a database table to a web service. This would mean changes at the Business Object and/or Persistence Layers but the Model Layer would not need to be altered unless new functionality was also required. This Model Layer is obviously the Model in our Model-View-Controller (MVC) UI design paradigm.

One of the interesting things that is emerging in ABAP Objects is much better security between classes. You will be able to set up friendship relationships between ABAP Objects classes to force developers to use the preferred interface. So in our example above, if you want to call some ERP functionality you will have to call the Model Class because the Business Object Layer and the Persistence Layer (and potentially the database layer as well) would all be "locked down". This makes a lot on sense on several levels, not least of which is if you implement business rules and logic at the Model Layer you don't want any mad old programmer bypassing them. Rememeber also this is the layer that implement the transaction processing concept so we certainly don't want anyone bypassing that.

Cheers

Graham Robbo