Skip to Content

ChaRM 7.1: New BadI to influence data in dialog window ‘Create Transport Request’ including example implemantation (Note 1772445)

As all of you know, creation of transport requests in the managed system of the project from the Change Request Management CRM Web UI is one of the ChaRM features. There were customer requests to be able to influence the data in the dialog window.

Starting 7.10 Support Package 8 (and downported to Support Package SP 4-7 via SAP note 1772445) there will be a new BadI ‘AIC_CREATE_TRANSPORT_WINDOW’ with which it is possible to influence the list of development systems in a project and the default system set in the dropdown.


The BadI has to methods FILTER_SYSTEMS and CHANGE_DEFAULT.

First Use case is f.e. that customers working with the Normal Change and having a lot of logical components (and with it different development and productive clients systems) in there project want to restrict the list of avaliable development systems to the development system of the productive system of the IBase assigned in the Normal Change. This would be possible with FILTER_SYSTEMS.

Even better, there is now a – per default inactive delivered – BadI implementation AIC_ONLY_DEV_IBASE_SYSTEM available to restrict it for the Normal Change.

To activate the implemantation:


Other use cases could be possible, f.e. restricting the creation of transports to special business partners dependent from the development system. Just an idea


Second use case to change the development system set per default dependent from customer logic. This is possible via method CHANGE_DEFAULT of the BadI

The interface of the BadI methods provide the parameters

IV_HEADER_GUID (transaction GUID)

IC_HEADER_BOL   (Reference to the header BOL)

It is then easily possible to program on CRM functions or (depending on BOL know-how) getting all current data via coming from the BOL header instance.

For the filtering with method FILTER_SYSTEMS there is a changing parameter for the system list


For the CHANGE_DEFAULT method we provide additional the system list as an importing parameter and the set default development system as an exporting parameter.


Further on, I would like to remind that there is already a BadI /TMWFLOW/SCMA_TRANS_REQ_DESC with which you are able to change the transport request description when creating a transport request.

So, hope this helps a bit,


You must be Logged on to comment or reply to a post.
  • Hello Michael,

    is there also a way of changing the type of transport which can be created via the pop-up badi? E.g. on client X01 only workbench and on client X02 only customizing transport requests?

    Best regards


    • Dear Carsten, unfortuantely not, you would need to create a overwrite method in enhancement in method DO_VIEW_INIT_ON_ACTIVATION of class CL_AIC_CM_T_TRANSPORTREQP_IMP.

      Just call the standard method and then program to your liking,



  • Hallo Michael,

    I realize that this already an "older" blog but I hope you are notified about comments and willing to answer some of my questions..... 🙂

    Some specific question I have:

    • The Badi makes it possible to create a one to one relationschip between the Production Ibase Component and the transport creation for the related development system of the Ibase Component. Is this someting that SAP strongly advices to setup, or is possible to use multiple transports with different production end targets within a single normal change even without using Central CTS?
    • How does ChaRM behave when I have mutliple transports with different production end targets in one normal change and, I enter the preliminary import flow of the normal change? Does the system start for example two import actions based on the preliminary import action / status?
    • What does the Ibase Component refer to when having multiple transports for diffrent target production systems in this situation or even when using central CTS?


    Guido Jacobs


      Hi Guido,
      in General, there is no advise from SAP. This depends on how your Company is structured and organized. The normal Change is the change document for Project-based Import which means for the big and often for the cross developments with multiple systems.
      Therefore, you are able to create Transports for all Systems in the Change cycle. In case, you have developers which work only in one System, I would expect that they do not have authorization in the other Systems. Which means, the creation of the Transport would fail.
      Multiple Transports of different Systems work as well w/o cCTS.
      The Imports are scheduled by one Task list Job and imported sequencially but in one process when using preliminary import. The Thing is that if you create Transports for multiple production Systems in one normal Change, it is assumed that the Change you do, will work only together. So, it has to be imported together.
      About the ibase. The field is a one-value field, so you should maintain the main production System here. I am not sure if you are on 7.10 or 7.20 but I assume 7.10. Because on 7.20 we have the config item. There is as well a 'Referenced objects' ass. block and I think in the case that you create an additional Transport request for a another production System which config item is not maintained, the config item of the second production System for which you are creating the Transport should be added to the 'Referenced Object' ass. block for reporting reasons.
      I will put this requirement to our backlog,
      best regards and hope that gives you some answers,