creation of superclass for reusability, how to define DDIC types in methods?

[robphelan]

Hi everyone,

For our inbound interfaces, I'm planning on creating a superclass for each BAPI we'll be using. Within it, I'll have a method for each table/structure that the BAPI can accept.

For example, we are using 'BAPI_ACC_DOCUMENT_POST'. I have created a superclass with the following mapping methods:

• HEADER_MAPPING
• ACCT_GL_MAPPING
• VENDOR_MAPPING
• CURRENCY_MAPPING
• TAX_MAPPING
• EXTENSION_MAPPING

To make the superclass reusable, I plan on passing in data using TYPE REF TO DATA in the constructor method. However, in my mapping methods, how can cast that into something useful (at the superclass level)?

Or, do I just have to wait until I inherit it out to a subclass, then declare a specific DDIC to cast into?

Hope that makes sense.

Robert.

[Sandra_Rossi]

It's called overengineering. I can't imagine that you gain some time with publishing an API of an API.

[robphelan]

"It's called overengineering"

It certainly is that.

We're implementing a new instance of SAP and we'll be using an SAP product called AIF for most of our inbound interfaces.

It's basically a mapping/translation and process orchestration framework.

A lot of this work will eventually be done offshore, and I want to make sure those processes being orchestrated are as reusable as possible in no matter what interface/posting process is being performed.

A problem this company has had is inconsistent processing. Some interfaces do this, others do that. I want to simplify and standardize those flows so that all AP docs post the same way, and all POs are created the same way.

So, I plan on designing out the posting framework to make sure they are being consistent and that the same processes are being consistently followed.

[matt]

You can simplify the BAPIs. You can also bundle changes, for one final commit - for sequential operations. I've done this for the user maintainance bapis. It makes them a lot easier to use.

[Sandra_Rossi]

Very good idea. It could be the same logic as Specifying Tasks for Adobe Forms, or OLE flush.

[Former Member]

Sounds like you want something like the Strategy Pattern.

[robphelan]

Hi Armin, I hadn't heard of that before, but yes, it's very similar in how I want to design the posting classes.

I want a level of abstraction away from the superclass to make sure the basic template is there and so that a developer can come in, inherit it out for their own needs while not touching other existing posting classes.

[Former Member]

Then you should give the pattern a try. I'm sure you can find many about it in the net.

[kesavadas_thekkillath]

Hi Robert,

Okay, I understood what you are intend to do, but imho, this looks like over kill, mapping different structure into a inheritable sub classes is a bit complex. Even if you pass via reference, it has to de-reference into different structures internally some where.

May be something like a abstract super class and inherited sub classes will do. You can play with type any / RTTS classes etc. Lot of effort

As you asked refer these links for startegy pattern, note that in below links Strategy is implemented using Interfaces and not abstract class.

You can also refer to head first design patterns book for understanding design patterns.

[robphelan]

Thanks..

i think i figured out what i'm going to wind up doing.

We plan on funneling all similar inbound interfaces into "interface flows".

For instance, let's take AP:

We have 10 sources of Vendor invoices. They ALL do the same thing once we get them into SAP - create an invoice (FB01). However, file formats are different.. certain invoices need additional enriched data etc....

All that enrichment and validation will be handled in an AIF action.

BUT, since they all basically do the same thing, the converted data will all flow into the same Ztable.

We build a single workbench on top of this Ztable for error invoice verification and posting.

What I will do is create a superclass for the AP posting and instead of making it so generic, I'll be using the structure of the Ztable.

That way all subclasses will use the same DDIC structure because all the data is stored in the same Ztable.

This is actually how I have my existing AP interface flow setup currently.

I was just hoping I could find a way to have 1 superclass that inherits to any other AP subclass even if the DDIC structures would be different. But, as Sandra pointed out above, that is really making an API out of an API.

[engswee]

Hi Robert

Your scenario is quite similar to something I faced on one of my previous organisation. I incorporated a strategy pattern based framework in order to streamline commonly used codes. It was designed for IDoc based interface and I haven't used AIF before, but some of the concepts hopefully may be helpful for your case.

I've blogged about it in the link below, and in part 2 I've also included the source codes in SAPLink's NUGG format.

Regards

Eng Swee