SAP for Utilities Discussions
Connect with fellow SAP users to share best practices, troubleshoot challenges, and collaborate on building a sustainable energy future. Join the discussion.
cancel
Showing results for 
Search instead for 
Did you mean: 

Performance issue while using 'BAPI_UTILINSTALLATION_CHANFACT'

Former Member
0 Kudos

Hi,

I have used the BAPI BAPI_UTILINSTALLATION_CHANFACT to update installation facts . But it is giving us a very low throughput in terms of performance.

Initially i had written the code in below order

1st BAPI_UTILINSTALLATION_CHANFACT and as soon as the control goes to the next statement check if the bapi had returned any error message and if no error messages are there call the BAPI_TRANSACTION_COMMIT (Without wait) for commit work and the whole thing was happening inside a loop as the BAPI can update the installation facts for one installation at a time.

Then we changed the code to call the commit once we had processed 1000 installations instead of calling it after each installation is processed. But that also didn't help improve the performance much.

I am looking for any other BAPI/FM which can efficiently update the installation facts with a good throughput?

I have got one recommendation to use ISU_S_INSTLN_CHANGE FM instead of BAPI as the loading of BAPI function group will take more time it may be causing the performance issue. But when i check inside the BAPI , it is also calling the FM ISU_S_INSTLN_CHANGE to update the facts. But if i have to use the FM ISU_S_INSTLN_CHANGE first i have to call the FM ISU_S_INSTLN_PROVIDE to get the installation details. So if i replace the BAPI for using ISU_S_INSTLN_CHANGE, effectively i will have to call 2 FMs:

ISU_S_INSTLN_PROVIDE

ISU_S_INSTLN_CHANGE


Can you please advise on how could i improve the performance or have a good throughput in updating installation facts?


Regards,

Deepak

6 REPLIES 6

william_eastman
Advisor
Advisor
0 Kudos

Deepak:

What is the use case?  installation facts update will not have great throughput in general - are you parallelizing the update?

regards,

bill.

0 Kudos

Hi Bill,

We are trying to update two installation facts of operand type quantity and user-defined for 24 Million data.

Yes, we are using the parallel processing rather i would say the mass activity approach where we have used a custom MRU object as the parallel processing object... but there is a limitation that we can only provide the number of parallel jobs as 20 as we are updating some custom tables also (by using enque and deque ) in the program and if we keep the number of jobs high then we are getting job failures saying lock table overflow issue. And i believe it is getting generated if we try to update/lock more than 56000 records (records getting updated should not be more than 65 MB)  at any single point of time. Hence we have reduced the number of jobs so that number of locks/records will be less than 56000.

The information about lock table overflow and the system parameter maintained maximum for 65MB is the optimum parameter which i have understood from basis team.

Is it something related to Commit work?

Regards,

Deepak

0 Kudos

Deepak:

Do you have TQM or max attention engaged?  This is one type of challenge that they are designed to assist.  Especially regarding the lock overflow, which seems like a hardware or program design issue.  Mass activities in ISU can generally handle a significantly higher number of concurrent processes via parallelization.

regards,

bill.

Former Member
0 Kudos

Dear Deepak,

Although I don't suggest this way due to its risks of creating inconsistencies of table ETTIFN, you can use ISU_INST_FACTS_UPDATE FM. Before the FM, select ettifn that you want to update and then construct your new table and give it to the FM.

But you should be careful and run some tests on QA system before running it on production. Additional note: This FM does not produce any change docs.

BR,

Eren Adak

0 Kudos

Doing it that way would not be a good idea, especially for such a large dataset.  Since the FM is not released, issues due to its use would not be supported. 

Former Member
0 Kudos

Hi Deepak,

I would suggest below:

- Use FM ISU_S_INSTLN_PROVIDE & ISU_S_INSTLN_CHANGE. This will have better performance than BAPI. BAPI also creates a Bdoc even though no corresponding replication is required at CRM end.

- Committing after 1000 seems on higher side; it will have negative impact on performance with increase in number of parallel processors. Try with 100 or so; optimum value also depends on the system but still 1000 is on higher side.

- Number of concurrent SAP locks seems too high, it should not be like this. Are you releasing locks on time? could be related to delayed commit. If the custom updates are simple in nature then may be try using update FMs.

Regards,

Pranav