Collections Management (BRF and Work items) performance

[ivor_martin]

Hello Colleagues,

We are in a project with a large customer base (over 2 million), and are using Flexible Dunning (Collections Management) with BRF (not BRFPlus).

We are also using Collections Work items via IC Web client.

We are not live yet, and are in the build/configuration stage.

The question of performance regarding the Dunning run as well as online CRM Work items has been asked.

If anyone has any Collections Management performance feedback from actual go-live experience, or through testing, I'd really appreciate it you could share it with me.

For example, I have heard from some sources that too many BRF context look-ups from  the open Item table DFKKOP causes performance issues in batch Dunning.

Thanks in advance.

Regards,

Ivor M.

[Former Member]

Hello Ivor,

It's NOT recommended by SAP to use BRF... it has a lot of issues, including performance.  Try to reconsider your solution approach including BRFPlus NW7.02 (at least).

Maybe would be a good idea to check these links first:

http://scn.sap.com/docs/DOC-4559

http://scn.sap.com/community/brm/blog/2010/07/21/performance-in-brfplus-surprise-surprise

http://scn.sap.com/docs/DOC-23175

Regards,

JC Salas

[william_eastman · Accepted solution]

Ivor:

Performance in BRF or BRF+ is greatly dependent on design.  You are correct that certain types of expressions, e.g. reading context from DB, can cause issues.  That is where design comes into play and ensuring that DB access is executed properly.

If you write your rules well, then performance as compared to dunning procedure will be better.  But bad rules can and will cause issues.

CRM work item processing performance would depend on your view definitio, the processes you support in the IC, and the landscape and connections to ERP.  The core work item process is not a performance issue.

Juan mentions BRF+.  Generally speaking, if you are starting a project now, then BRF+ is the suggested approach.  Obviously that also depends on the system landscape.  So if BRF+ is not available in your systems (there are blogs in the BRF space http://scn.sap.com/community/brm/content which indicate the correct levels at which BRF+ exists), then using BRF is an appropriate solution.   I will assume that you have already analyzed your situation to determine the right approach.

The same essential questions exist whether using BRF or BRF+. Bad rules design will decrease performance.  This is mitigated by consulting and testing, of course.  This is true in rules as much as in a program/function. 

One tip from my experience - if you find that you are using context data retrieval heavily, then maybe you should use event 315 and provide it naturally rather than to select it via an expression.  Context retrieval should be limited as much as possible to data that is not needed for all evaluations.

regards,

bill.

[ivor_martin]

Thanks Bill.

I`'ll keep the Context data access in mind and use 315 for complex retrieval.

Regards,

Ivor