Usage of BRF+ tool in BW for a complex rule

[former_member188972]

In a BW project it's quite normal to have some “conversion rules” inside of the BW model data, but normally you are thinking something like that:

ECC doc type converted in BW document type depending on source system.

It becomes a problem when the business requirement is very intricate, you potentially need a lot of coding (bad coding) to reach the achievement.

I report here part of the requirements that the user ask to me to define a new BW characteristic to identify the strategy of definition/assignment of purchasing contracts.

Moreover, you can have many changes also after a correct running, cause of re-engineering of the process (or more simply the customer realize a different need during the real usage).

It is a very complex elaboration.

So, I get that the BRF+ should be a great allied to minimize the ABAP code and the post go-live re-work.

This is the result. A decision tree with calls to 5 decision tables.

I split in different tables to reduce the complexity of the logic.

Each group have a subset of the characteristics not the full set. And with a decision table

One of the decision table is the following (extract):

I love it, because every cell is a condition and I have many elegant feature. I used some of them:

• General condition (here defined “true”) to define that cell condition is true for all values (in my requirements you can see “for all values”).
• The values are prompted directly from the value list of the infoobject. Sometimes I had very strange textual values. So I was sure to capture the exact value, in ABAP is little more laborious.

To use the BRF+ function in the BW transformation I have generated a function module with the help of the standard program FDT_TEMPLATE_FUNCTION_PROCESS.

Finally, the BW transformation call the Function during a start routine:

……………………………………………

……………………………………………..   

   LOOP AT SOURCE_PACKAGE ASSIGNING <source_fields>.

      CLEAR:  vwmtrv, garaue, zshcmsaca.

CLEAR tb_zstrat_***.  “It is the structure used in the BRF+ container

      tb_zstrat_***-zshtiprev = <source_fields>-/bic/chcttprev.
      tb_zstrat_***-zshadesaq = <source_fields>-/bic/zshadesaq .
      tb_zstrat_***-zshdocvol = <source_fields>-/bic/zshdocvol.
      tb_zstrat_***-zshvwmtrv = vwmtrv.   

tb_zstrat_***-zdoctype = <source_fields>-doctype.
      tb_zstrat_***-ZSHCNTSAP = <source_fields>-/BIC/ZSHCNTSAP.

*assignment strategy
CALL FUNCTION 'ZSTRASS_***'
EXPORTING
zstrat_***    = tb_zstrat_***
IMPORTING
strategia_*** = wa_strategia_***.

<source_fields>-/bic/chctstass = wa_strategia_***.


ENDLOOP.

…………………………………………….

…………………………………………..

Personal hint and point of attention

Make a clear analysis (monsieur Lapalisse said).

In specific it’s important to sort the different cases in the exact order that you want consider in the develop. It helps to avoid overlaps of conditions and empty combinations.

If the requirements become very complex in term of conditions and number of cases, some combinations may be not considered in the analysis. I have introduced a dummy condition (final) for all of these to report this kind of exception.

There is a pretty function “Check Completeness” but in a very complex table, you can get a wrong message.