MBO creation with custom ABAP BAPI/FM - Best Practice??

[mike_reader3]

I have created some MBOs based on custom BAPI/FM's and the
apps work fine. The question I have is more around the setup
of your MBOs. Consider this situation:

You have a custom "Z" table in SAP (lets call it ZCUSTOMER).
You write a custom BAPI/FM (call it ZUPDATE_CUSTOMER) that
takes in a customer number and name and updates the name
with the name that was input (I know this is dumb but stay
with me).

Now, when I am in SUP, and ready to create an MBO, should I
be first creating another BAPI/FM to just strictly read the
ZCUSTOMER table, as it seems that SUP wants to base its MBO
creation off of a read rather then an update? Then create an
Operation on the MBO that would use my ZUPDATE_CUSTOMER?

If I create the MBO based on ZUPDATE_CUSTOMER, the mbo will
work fine, it looks a little strange when I am designing the
app itself b/c I can actually call the generic "findAll" and
it invokes my FM/BAPI and does an update.

A lot of the examples I have read regarding MBO creation,
shows creating an MBO based off of a table, then creating
your operations (via SQL usually).  This makes sense to me
b/c the table represents the data. Obviously not something
you want to try in SAP though.

Creating an MBO from a FM/BAPI (other then one that strictly
does reads) does not seem to be a best practice to me?? On
the other hand, I do not always want to have to create a
custom read BAPI/FM every time I create an MBO.

I am an ABAPer turned SUPer (recently) so maybe I am missing
something here.

Would like to here what you other ABAPers are doing out
there.

Thanks, Mike

[rakshit_doshi]

Hi,

Creating an operation on a BAPI and linking that operation to another BAPI will help but not in all the scenarios.

Lets say for example you have two Custom BAPI's Z_A and Z_B.

Z_A has input parameters a_a,a_b,a_c and it returns a table as an output containing many fields say name,lname,address,state,city,id,sex etc

Z_B is a create operation in the RFC. If you create an operation named CustomCreateOperation on the MBO created from Bapi Z_A and bind that operation with Z_B it will work fine.

But say in case of a scenario that Z_B has an input as a structure and it gives out a string as output for the values posted in the structure..For eg you are trying to Create a GR for a PO from device.

ABAP people might know that for every posting we generate material document and for blank data no material document is generated.

If you are using a custom operation first difficulty you will encounter is that you will never see the output parameter of the MBO referenced to Z_B created from the operation in the generated code and somehow if you are doing some up and down and seeing that thing you will never be able to read it synchronously.

Try it out keeping a debugger at the BAPI. It will always be called twice.Once with the data that you pass and second one with blank value and the time between the call will be so instant that you wont be able to read the material doc no generated in between.

Try it out.

[mike_reader3]

Rakshit ... just curious ... I am using LOG-POINT's to see how my BAPIs are working when testing an App, what have you found that works for debugging?  (I know this is unrealted to this thread - just something I was wondering after reading your post).

Thanks, Mike

[rakshit_doshi]

Ya i used to keep external breakpoints in the BAPI. When you call a function from the device you can check the entries and the data you get in the BAPI.

This is very helpful in debug even to know how many times the BAPI is been called.

Hope this helps you somewhat.

Thanks,

[markteichmann]

Hi Mike,

these are interesting questions. I am facing the same problems at the moment.

From my point of view the whole MBO design originally was designed for SQL databases. Therefore an UPDATE FM does not fit into the concept very nicely.

I think you should create a seperate READ FM for every UPDATE operation.

Currently I am trying to read service orders from SAP. Because they are very complex I need to replicate them to the SUP and synch only relevant orders to the mobile clients. But at the moment I have no clue how to model the MBOs for best performance because I need many MBOs for one service order and they have to be replicated together.

[mike_reader3]

Hi Mark,

I did get in contact with someone from Sybase regarding this, basically this is what I found out...

When you create an MBO from an SAP BAPI (let say in this case it updates a table and returns a success/fail message), then you are basically locked into using the default findAll query as this will allow SUP to return your message.  The Sybase resource agreed with me that this seems a little strange but for now this is what we have.

There are many cases where I do not want to create a "Read" BAPI for an app, and I guess the above is the solution ... for now

Here's hoping new versions of SUP address MBO creation from SAP BAPIs.

-Mike

[Former Member]

I think it's rare that you would only "create" an entity from a mobile app, without ever doing a "read". 

The pattern is typically:

1) Retrieve a list of items. 

2) Drill down into a specific instance to view the details

3) From there, click an Edit button to enable the fields for editing;

4) Or - select it from the list and delete it;

5) Or - click a "New..." button to navigate to an empty detail screen and fill in the required fields.

Therefore, I would offer this alternative.

Create the MBO from a getList BAPI.   That gives you your "read" operation.  If you have BAPIs that do create/update/delete operations, add those as operations on that same MBO.  That's much more object-oriented than creating an entirely separate MBO for the "create" operation...

-Paul Horan-

SAP Global Mobility SWAT

[mike_reader3]

Hi Paul, thanks for the reply.  How would you suggest handling the above situation you described if you wanted the create / read operations in different cache groups?  I assume you would need two different MBOs in that case.

-Mike