RFC and BAPIs Working Slow at MII Workbench

[aelmaser]

Hello community,

We're using MII Workbench 15.2.3.0 at our company. We're trying to send production confirmation with using BAPI_REPMANCONF1_CREATE_MTS to SAP from MII workbench. As you can see in the Appendix, we started with an Action block (Sequence95 - start_2) and in that we added our SAP server connection parameters.

Then in Sequence96 - SAP_JCo_Function_0, we used BAPI_REPMANCONF1_CREATE_MTS and filled the request columns with our values. Then used BAPI_TRANSACTION_COMMIT at Sequence97-SAP_JCo_Function_1.

We also used RFC at Sequence_107 in the same transaction.

When we run this transaction, it works but it works really slow. For sending one record to SAP from MII, it takes 10 seconds approximately. We have to send 100 records in like 5 minutes so this is not good for us. Is there any way to speeding up this RFC / BAPI processes ? Is MII Workbench limiting us ?

Edit : After some researching, running the BAPI_REPMANCONF1_CREATE_MTS synchronously is the main problem I guess. But when I run it Asynchronously, production record for that material cannot be seen in MB51 area. And I have to match the Confirmation code which I receive from the BAPI_REPMANCONF1_CREATE_MTS's response for all sent production records . Is there any way to decrease the running time of BAPI's when running it synchronously ?

Thanks,

[Ulrich_Schmidt · Accepted solution]

There is no easy answer to this, because the possibilities of where the bottleneck is, are just too manifold:

• some non-performant Java coding on MII side
• slow network between the MII system and the ABAP system
• some non-performant ABAP coding in FM BAPI_REPMANCONF1_CREATE_MTS (e.g. badly designed SQL statements, etc.)

So the first thing you need to do is to find out where exactly the time is lost. You could add some timestamps like at the very beginning and at the end of your workbench flow, at the beginning and end of the JCoFunction.execute() and perhaps even on ABAP side: create a small wrapper of BAPI_REPMANCONF1_CREATE_MTS which takes a timestamp at the beginning and end, and does nothing else but calling the real BAPI_REPMANCONF1_CREATE_MTS, passing all the inputs.

Then there is a useful feature, you may be able to use: JCoThroughput. (Read the JavaDoc on that.) It gives you the times that JCo needs internally for processing the data, and the time between the points where JCo starts writing data to the network connection and where the backend's response starts arriving on that connection. So this time is basically "network time + time the ABAP code needs". If you subtract the time obtained from your wrapper FM from this number, you get the network time.

With all these timestamps, you should get a clear picture of where the bottleneck is, and then you can start optimizing this particular part of the end-to-end process!

[aelmaser · Accepted solution]

Hello Mr. Schmidt,

Thanks for your descriptive answer. As you pointed out, we are trying to find where the time is lost. I've created timestamps before and after the JCo function which runs the BAPI_REPMANCONF1_CREATE_MTS. And I've seperated Start Action and End Action blocks from the repeater. It took way more time to complete comparing to another running RFCs / BAPIs. Now we focusing on the ABAP's running time. I couldn't use the JCoThroughput feature but we'll test the ABAP in SAP's ST05 and ST12 screens. 

I'll update this message after the tests and conculutions. 

Edit 30.07.2024 :

We've tested BAPI on ST05 and ST12 screens, and I added the result at the end of this message. So it was really the BAPI that takes too long to process. (Yellow rows that indicates BAPI's steps. And I couldn't found all the BAPI steps in that row jungle yet.) The time was 8 seconds and the result shows nearly 7 seconds of that spent on BAPI.

I hope someone will gets benefit of this post in the future.

Thanks,

Alper