Skip to Content
Technical Articles
Author's profile photo Vadim Kalinin

Calculations in Write Back BADI – Default.lgf Replacement

In this post I want to describe the concept of performing calculations in the write back badi instead of default.lgf. Let’s assume that we have some default.lgf with a number of *WHEN/ENDWHEN loops doing some calculations like price*quantity, price*quantity*(1-discount), etc. If you have a lot of formulas the calculation time can be significant and users will have to wait saving data in the input form.

Difference between default.lgf and write back badi:

Default.lgf

Benefits:

Easy to maintain

Easy to copy data to another model using *DESTINATION_APP

All checks are done automatically (security, work status, write to calculated members etc…)

Issues:

Execution speed (even with ABAP calculation engine for BPC 10).

Unnecessary calculations can be performed (default.lgf scope is a combination of all members of sent data!)

Hard to generate multiple records triggered by single member change (example – single price for the whole year in some member, update all months amount)

Write back badi:

Benefits:

High execution speed.

Only sent data will trigger the calculation (write back badi receives the table with sent data, not the scope).

Easy to generate multiple records having single value sent.

Issues:

Hard to maintain (ABAP developer required).

Write access have to be checked before calculations.

Special code have to be added to write to the different cube.

Write back badi sample logic:

1. All data sent by user from a single EPM/EVDRE report will be passed to write back badi as a table (including parent values).

2. Only members used in formulas will be processed by badi calculations, the rest will be processed by default.

3. Initial write to the cube with create_write_back and write_back will be done inside badi to ensure that the sent values are stored (removing rejected records from calculation process).

4. Reference data (data for members used in the formulas but not existing in the sent records table) have to be read from cube.

5. Number of functions have to be defined – each representing the ABAP code of the formulas required.

6. Table with original records saved in the cube and reference data records have to be processed by the functions from previous point.

7. Calculated records have to be added to original ct_data to have correct messages.

8. If write to other cube is required then it have to be implemented with create_write_back and write_back.

9. At the end of badi ct_data will contain original records and calculated records. This table will be written to the cube generating correct messages.

B.R. Vadim

Assigned Tags

      17 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Ivan Blatnik
      Ivan Blatnik

      Hi Vadim,

      just one comment to the list of default.lgf benefits:

      I noticed, that work status for the *DESTINATION_APP is not checked in a proper way. It does not show as an error when executing default.lgf during save. It just doesn't update receiving model so it creates inconsistency between sending/receiving model.

      Is this a bug?

      Regards

      Ivan

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      Hi Ivan,

      It's a bug/feature 🙂   You have to use some administration procedures to keep work status in sync when you use destination app.

      Vadim

      Author's profile photo Former Member
      Former Member

      Hi Vadim

      Just one comment, one of the main benefits of write back BADI is that it allows users to send data at non-leaf node. And then further processing can be defined to handle this record and then only leaf members can be added to ct_data. This can be big advantage where user wants to adjust aggregated values directly. Also do you know, how such functionality can be managed in BPC M ?

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      Hi Anurag,

      Ability to "send" data to non-leaf node is the side effect of write back badi 🙂 . Simply because that write back badi will receive all data sent by user, even to the read-only members like nodes, members with member formulas, members with locked work status, etc... The code inside write back badi can check for this conditions and process this data somehow: disaggregate to base members, redirect to some base member, etc.

      Unfortunately I have no idea how to do the same in BPC MS.

      Vadim

      Author's profile photo Ivan Blatnik
      Ivan Blatnik

      Hi Vadim,

      I have another issue with *DESTINATION_APP.

      I have two models: HR and FI. In HR I have dimensions HR_POSITION, COST_ELEMENT, etc and in FI only COST_CENTER, COST_ELEMENT etc.

      In my
      default.lgf I have following script:

      *DESTINATION_APP = FI
      *ADD_DIM AUDIT_TRAIL = PAY
      *ADD_DIM COST_CENTER = HR_POSITION:COST_CENTER
      *SKIP_DIM = HR_POSITION

      *WHEN COST_ELEMENT
      *IS PY_SALARY, PY_NI, PY_ADDITIONS, PY_SUPERANN
      *WHEN HR_POSITION.EMP_TYPE
      *IS E, V
      *REC(FACTOR = 1, COST_ELEMENT = 401001)
      *IS A
      *REC(FACTOR = 1, COST_ELEMENT = 401040)
      *ENDWHEN
      *ENDWHEN

      If I save this values then result in FI is 300.

      Value
      POS1 100
      POS2 200

      But if now I change POS1 to110 after save value in FI is 110 instead of 310 (110+200).

      Value
      POS1 110
      POS2 200

      Is this
      correct behaviour? Does it mean, that we practically cannot use *DESTINATION_APP in default.lgf in this case.

      Thank you

      Ivan

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      Hi Ivan,

      The question is not directly related to the blog subject, please open a new discussion, I will answer your question. Please also read my other document: How-To: Write default.lgf

      B.R. Vadim

      P.S. Also describe the content of the property HR_POSITION.COST_CENTER in the relation to HR_POSITION.EMP_TYPE

      Author's profile photo Former Member
      Former Member

      Hi Vadim,

      I am also trying to replace the default logic to a Write back BADI. I want the BADI to be triggered for input schedule and imports , have logic in the write back to do some calculations. The problem is the write back is triggering for input schedule(MAN) but not for DM filter. I added both the filters in the BADI but it does not trigger for imports.

      Any idea?

      Thanks
      Nik

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      You have done something wrong, write back badi is perfectly working with data send by DM package! Open a new discussion and provide all details including screenshots.

      Author's profile photo Former Member
      Former Member

      Thanks Vadim. I 've opened a new discussion for this .

      Author's profile photo Abhishek Mandlik
      Abhishek Mandlik

      Hi Vadim,

       

      How many maximum records can be passed to write_back method of SAP? We are calling a custom BADI through DEFAULT.LGF in which we are using this method and wanted to know the maximum limit so that we can loop the data to be written in package size.

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      Instead of custom logic badi in default.lgf it's better to use write back badi.

      Author's profile photo Abhishek Mandlik
      Abhishek Mandlik

      Thanks Vadim,

       

      What will be the number of records that write_back can write to the model? Is there any max. limit recommended? Thank you for your help!

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      There is no defined limit. Please open a new question in the appropriate tag and explain what do you want to achieve.

       

      Author's profile photo moufidi amine
      moufidi amine

      Hi vadim,

      can we run write back badi with runlogic ph badi to improve execution time of write back badi ?

       

      Thanks,

      Amine.

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      Absolutely strange idea! Write back badi is executed when data is save to the cube. No relation to runlogic_ph badi.

      If you have bad performance with write back badi then change your abap developer!

      Author's profile photo moufidi amine
      moufidi amine

      Hi Vadim, thank you for the quick reply,

      How can we improve performance of a write back badi without changing the abap code ?

      Can enabling ENABLE_PARALLEL_EXECUTION in spro do the trick ?

       

      Thank you in advance,

      Amine.

      Author's profile photo Vadim Kalinin
      Vadim Kalinin
      Blog Post Author

      "How can we improve performance of a write back badi without changing the abap code ?" - no! If you have bad code - you need to correct it!

      "Can enabling ENABLE_PARALLEL_EXECUTION in spro do the trick ?" - no!

      There is no magic solution to make slow code faster!