ABAP MDM Connection Pool

[michael_pang4]

Hi,

I'm trying to write a report that extracts information from MDM. Everytime it's called, it has to establish a new connection to MDM where the hand-shake takes about 20-30 secs.

I was wondering if ABAP MDM Connection Pooling exist.

In Java MDM, you can configure J2EE with connection pool, so that you can reuse a connection rather than re-establishing a new connection on every call.

I've read Thomas Jung's WIKI on "How do you implement a MDM Connection Help Class?", however I cannot reuse this class. The static attribute in the class is not persisted.

Did I do something wrong?

I tried turning it into a shared memory root class, however it complains about an object reference still exist and would not allow me to do "dettach_commit( )".

Don't know any other ways to store the connection handle in memory.

Export/Import, SPA/GPA are not OO friendly.

Cheers

Michael

[Former Member]

Hi Michael,

the Java-Api like connection pooling you described is not available for the ABAP API.

There is a huge difference in terms of architecture.

Within Java just the connections are pooled.

When you do a connect using the ABAP API the whole meta data gets stored to be able to work more efficiently afterwards (there is also a pure connection pooling by the way deep down inside the ABAP kernel. But that's purely technical stuff and not usable for the end-user.).

The ABAP API has been designed for applications that do a connect once and then work with that connected state as a basis.

As soon as you to do a connect for each action you should try to change your architecture to be able to use the ABAP API efficiently.

Regards

Andreas

Edited by: Andreas Goebel on Feb 22, 2008 4:36 PM

[michael_pang4]

Hi Andreas,

Thanks for your reply, it is good to confirm my understanding of the ABAP API connection.

For your interest, I have changed part of the connection code to increase the speed of the connection significantly.

Firstly to clarify, the connection from the ABAP stack to MDM is actually quite fast.

Upon the first call, the method CL_MDM_PROVIDER_SP04_PL03->_LOAD_FIELD_INFORMATION is called which reads the META-DATA from MDM for every table and every field. This could normally take 1 minute in our system landscape. I've changed to code to buffer the meta-data.

In a production/stable environment, it is unlikely for the META-DATA to change rapidly. Hence reading this on every connection is a waste of time.

This could be useful only if we are in implementation phase where this changes all the time.

1) In transaction MDMAPIC, I've added the ABAP implementation for MDM Version Support as my own MDM provider class ZSP04_PL03 with provider type ZCL_MDM_PROVIDER_SP04_PL03.

ZCL_MDM_PROVIDER_SP04_PL03 is a copy of CL_MDM_PROVIDER_SP04_PL03.

2) In ZCL_MDM_PROVIDER_SP04_PL03, the method LOADFIELD_INFORMATION is changed to read from buffer first before calling MDM. If the buffer is empty, it will read from MDM and store result into buffer etc.

I'm storing the information in a transparent table at the moment.

I buffer the three class attributes:

- mt_field_meta_data,

- mt_mdm_field_meta_data,

- mt_field_code2id_map.

As MT_FIELD_META_DATA is a complex structure (i.e. tables within table), I had to split it up into many different tables.

I can provide the code if you are interested.

Cheers,

Michael.

[Former Member]

Hi Michael,

good to hear that people are able to develop their own solutions

For us it makes no sense to specialize on such an approach, probably the next customer would ask why the meta-data does not get updated during each connection. This really depends on the use case and we have to cover all of them.

For 7.1 we try to speed up the caching heavily by using the MDM server cache. This should solve the performance issues as long as the repository stays loaded.

Kind Regards

Andreas

[michael_pang4]

Hi Andreas,

Yes, I understand this is not viable as a standard solution.

As you mentioned before this API is designed for one connection per execution.

You connect, query, and get out.

We are using the API in a way where it's not designed for, but I feel there must be people out there who wants to use this API the way we are.

But don't you think refreshing meta-data on every connection is a over-kill in the production environment, especially when it takes 30secs+ to do this (more for us) on each connection.

In scenarios where the meta-data doesn't change often, why is it necessary to read the same meta-data over and over again?

I've made it to refresh daily, but SAP solution should allow options for customers to switch on/off caching the meta-data and allow refreshing if there is a change in MDM (via standard transaction perhaps?).

Smarts can be put around this, in my laziness I've made it a daily refresh, or even triggered manually by flushing the cache transparent tables (SE14?).

Understanding there could be major changes to API and architecture in 7.1, do you think the nwe API can be used for the following scenarios:

1) Efficient Reporting/reconcilation of data between MDM and source systems?

2) We have an online web catalog that pulls data from MDM. Do you think we can implement this catalog using ABAP technologies?

The Java API appears to be in a more mature state than the ABAP API, although I think they serve different purposes.

Thanks for your help so far Andreas. Just want to make some suggestions from a customer point of view.

Kind regards,

Michael.