Skip to Content
avatar image
Former Member

BPCA - TBOM Maintenance

We are using BPCA with several customers with great success – it has been proven to provide a lean and
accurate test plan for upgrades, ENHPs, business functions, service packs etc.


We have typically defined only the critical processes and transactions for each organization.
This can be done in a very short time: Only 30%-40% of all processes should be
considered critical (and important for regression testing) so for example in an
organization using 2000 transactions, 700 would be defined in SOLAR01 and
assigned test cases. Divide this between the modules and each team has a small
work load.  TBOMS should be recorded for each and BPCA provides a neat trick for this – you can record the TBOM as a
result of your first time test. So no double work!


BPCA further reduces this load when using the optimizer (from version 7.1) which can analyze and recommend
to test only the processes that are influenced the most from the oncoming changes.
For a single ENHP upgrade this test plan typically can consist of only 40% of
the critical transactions , so now we are talking about 250- 300 transactions
to test – instead of a full blown 2000 transaction regression test that testing
companies might suggest and even complete.


To prove the validity of this concept we have compared the processes and transactions that needed
tweaking because of the change – to those recommended by BPCA. This result is a
90%- 95% hit rate: All of the bugs were in the zone recommended by the BPCA optimizer.


So our customers are generally happy with the BPCA tool and the reduction in regression test effort
that it provides.

The challenge is how to deploy the tool in the organization as an ongoing IT process, particularly the
maintenance of the TBOMS: in all organizations the ongoing customer process
maintenance and development creates a large amount of changes to SAP and
customer objects. This can bring some of the already recorded TBOMS to a state
where their objects have been changed and therefore their TBOMS are obsolete or
not accurate. So how do you make sure that the TBOMS are up to date and


SAP provides a BPCA report on Obsolescence Checks that gives only an indication as to which TBOMS
may need to be renewed. The documentation explains this:

"The TBOM status Out-of-Date indicates that the
TBOM is potentially obsolete. The obsolescence check is based on the comparison of the
changed objects in transport requests and versions with the objects in TBOMs. However,
the system cannot identify whether a changed object actually resulted in a
program flow change and actually outdated the TBOM."

more alarming is this statement on Analysis Results with Out-of-Date TBOMs:


"You can also run analyses with TBOMs that have the status Out-of-Date. This status is simply used to
identify TBOMs that are potentially out-of-date. However, the analysis results
are generally accurate. An out-of-date TBOM can only produce inaccurate
analysis results in the following special cases:


  • An influence is not identified
    although the analyzed changes do affect objects of a program flow.


This can occur when an object contains too few objects. New
objects have been added to the program flow since the TBOM was last updated.
The planned change affects only these new objects.


         An influence is identified although the analyzed changes do not affect the program flow.


This can occur when an object contains too many objects. Objects
have been removed from the program flow since the TBOM was last updated. The
planned change affects only these objects that are no longer relevant.


What SAP is saying is that the Obsolescence Check Report does not report on the main causes of TBOM
change! They are, as mentioned here, the addition or removal of objects from
the transactions' TBOM, not a necessarily program flow change. So if you are
adding or removing fields, data elements, functions etc. to a development
(which is standard maintenance work) these changes will NOT be included in the Obsolescence
Check Report. So we actually do not have an indication for which TBOMS should
be rerecorded.


One solution suggested by SAP is to track every CR and rerecord every TBOM influenced by it. This
approach is very cumbersome and tedious. It will create a large workload of
unnecessary TBOM recordings. The developer writing the code doesn't always know
the top process or transaction. Most customers will not agree to this load.


What we DO need is a savvy and robust Obsolescence Check Report that can be run periodically, say
weekly or monthly. It would check all the workbench change requests opened and
modified during the period reported and how they affect the TBOMS. This would
result in a list of TBOMS that definitely need rerecording because objects have
been added or removed from their object lists. The other TBOMS with only program
flow change will be mentioned as potentially affected.


With this report customers will be able to use BPCA and maintain TBOMS over the time with
minimum overhead.  Has anyone done this already? Any additional ideas would be welcome.

Best Regards,

Oded Dagan

Project Manager

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Oct 11, 2012 at 06:54 AM

    Hello Oded

    There is no best practice document available for handling TBOM updates as far as I know.

    Updating the TBOM's only makes sense if the program flow changes.

    After a support package stack has been applied, you can expect flow changes so it might be a good idea to update the TBOM's after performing a support package stack  or upgrade.

    Besides those you can recommend end-users / key users to update TBOM's when they are aware of flow changes in the business process.

    A possible solution could be to go for a more automated way to generate those TBOM's using eCatt or QTP.

    How to guides are available on the SDN wiki:

    Another option is using the test framework that is available within SAP Solution Manager and using the actual test runs to update the TBOM's (that's possible).

    You can also recalibrate TBOM's to change the status into "Updated" again if you know only small changes took place:

    Best regards


    Add comment
    10|10000 characters needed characters exceeded

  • Sep 21, 2016 at 05:34 PM


    Anyone has additional ideas for 2016?

    I feel that TBOMs maintenance did not improve much since this post.

    Any news regarding the 7.2? Also, does anyone know how to size TBOMs ?


    Add comment
    10|10000 characters needed characters exceeded

    • Hi Alexandre

      I would have to check in regards to 7.2 but one way to update them regularly which is already available in later 7.1 versions is to use CBTA to record "automated" test cases and let those CBTA tests update the TBOM's so you have automation of the TBOM generation.

      Best regards