Testing BAPI wrapper functions

[Former Member]

Hello All:

Can someone please explain how can I test BAPI wrapper functions in Production MI server for xMAM syncbos? During development we set the RFC connection login to our userids so we were able to execute BAPI wrappers in the backend and look at the data at ECC to see what was supposed to be received in the middleware. This way we can quickly identify if the problem was a data issue in ECC or an xMAM config problem so on.

But in production ALEREMOTE is used for RFC connection to backend, and as MI admin I don't have the permissions to SM37 in production ECC system so I cannot run the BAPI functions to see data returned the function. It is making debugging time consuming and I was wandering how you all handle this problem?

I know there are some tables in middleware to show data from replication database but in case of S01 type syncbos I don't know where to look.

I appreciate your help or any pointers you may direct me to. Right now I have a problem with MAM30_010 where it is giving me error saying that work center for user xyz doesn't exist.

Also I was told by consultants who implemented our mobile solution that running the BAPI wrappers can cause . Do you agree with this ? I can understand the ones that create or change data should not be run, but is it dangerous for example to call MAM30_011_ GETLIST in the backend to see what it returns?

Thank you,

[Former Member]

Hi,

the problem you are facing is not that big as you think off - you can run the GETLIST/GETDETAIL handler directly in the backend in your case and enter the user name as parameter there.

You mainly talk about the MAM30_001 and MAM30_010 BOs. These are both S01. Have a look into MEREP_PD on the middleware to see the type of the BO. A S01 SyncBO gets all information always directly from the backend. So whenever you run a sync the Middleware asks the backend for the most actual data by calling the GETLIST and GETDETAIL handler with the SyncUser. So you can run the GETLIST and the GETDETAIL handler always manually. As you are right, CHANGE, CREATE and DELETE handlers are not so good to run manually, cause they have a real impact to the persistence. On the other hand it sometimes makes sence. Lets say you create a TimeEntry (MAM30_005) on the device and the error you get does not mean anything to you. Then you can take the data from MEREP_MON and run the CREATE handler manually to see the more detailed Error output of the handler. But in that case be aware of the impact and have the authorisations to correct false created entries.

If your work center for a user does not exist - check the master data and check the users setup in SPRO - depending which user we are talking about. If it is the device users work center you need to check the setup in SPRO. Then, after it was changed, replicate this data again (MAM30_090 and MAM30_095). Check the Data in MAM30_050 as well as the master data for partners in the backend. One of these two things will show you the problem. It should be the master data on the backend that is wrong, has not much to do with the device - most likely.

Hope it helps to solve your issue.

Regards,

Oliver

[Former Member]

Hi,

One option, I know the way you can check data for S01 syncbo's is using the monitor. You can use the transaction "MEREP_MON" and search the entries for a particular deviceid and it lists down all the syncbo's associated with the device and shows all the inbound and outbound entries for each syncbo.

(If you have a question of how to find a device id, then in the MI client-> go to Settings-> and copy your device id.)

It shows all the entries related to each sync and also shows the corresponding outbound entries. You can take the sequence number from the inbound queue and look for the corresponding entry in the outbound queue. This way you can check what has gone through client-middleware-backend and viceversa.

Regarding your last question, executing the GETLIST and GETDETAIL bapi wrappers should never cause any problem because, for finding out actually the problems we do use the bapi wrappers on the backend directly to check the output for each user.

Even using CREATE and UPDATE bapi wrappers is not a problem but the only concern here is

1. With create, you should be knowing all the mandatory parameters and you should manually enter it or you can even create some test data and check.

2. With update, you should send all the parameters which were earlier present in the backend system along with some of the modified fields, which is a tedious job. Missing out some fields while doing so, will update the record in the backend system with null values. So it is not recommended to use update bapi wrapper manually.

Hope this clears your questions.

Best Regards,

Siva.