We had a discussion yesterday about how it would be possible to simplify the SAP integration with 3rd party development tools for mobilizing R/3 or ERP based business processes. My belief is: It can't!

Let me explain why: it is really simple to configure a tool to use a database table as data source. Once you have done that with one db table, you can do it with everyone. From the table definition itself you can see which are the primary keys and the mandatory fields. With SAP function modules and BAPIs however, this is not possible.

Can you imagine writing a universal tool which allows you to access every Java library in a simple uniform way? That's what the tool must do with ABAP and at least Java is well documented in comparison ;-)

Function modules can have import and export parameters. This is the simple part - import parameters are handed to the function module, export parameters are returned. But then there are "changing" parameters and "internal tables". Both can either be handed over to the function module or they can be return parameters. You can't tell from seeing the interface of the function module. So either you have a documentation of the function module (which most of the time is not available) or you have to look at the code of it and most of the time you need to execute and debug it within the system. For that, you need SAP and ABAP know how and often it is a challenge for even an experienced ABAP developer.

The second thing is that there is no common uniform way in which function modules are developed at SAP. There are different teams who work on different SAP modules and everybody is doing it differently. So if a HR expert has to work with function modules from PM or CS, he will have a hard time. He will also be required to dig into the ABAP code to find out how exactly the function modules work.

So the ideal solution would be to have somebody with good SAP functional knowledge and ABAP know how who worked with the function modules of the SAP component that you want to mobilize.

If we look at SAP NetWeaver Mobile 7.0, they went a different way: They defined how a function module must look like in order to work with their tools. In order to mobilize a function module, it must follow the BAPI Wrapper rules. Now you are able to just say "Mobilize it for me" and the SyncBO is created. The drawback with this approach is that you are always required to write additional custom ABAP code.

On the other side I think that this is a good thing. The SAP function modules were not designed to be used in a mobile scenario: Most of the time, they deliver too much data and they are too complex. Often the data is not formatted in a client friendly way either and it's so much easier to centralize the management of this on the server side rather than on the client.

So if we look at mobile scenarios, we at msc mobile will create our own function modules anyway. Internally they will call the standard SAP function modules and then only deliver the required data to the SUP middleware. Doing this, we are also able to call multiple function modules within ours and combine the data that they deliver reducing the number of client to server transmissions.

I like the open approaches, but they come with the drawback of great complexity. There are two things I could think of to make life easier for developers without SAP knowledge:

The first thing would be to give them a cookbook/best practice guide that tells them how the perfect function modules (for read, update, create and delete) for the tooling would look like and how to mobilize them with it. This would help the ABAP developers to understand how the function module needs to look, even if he has no knowledge in the 3rd party dev tool. And it would help the mobile experts to easily call these function modules.

In a second step the 3rd party dev tool could be extended to read function modules with a defined interface and mobilize them without the need for a lot of configuration. Again, this interface must be documented, which makes it easier for the SAP guys to deliver the right thing.

However, I would not get rid of open approaches - this would make the tool less flexible and therefore less attractive.