ActiveControl supports SAP customers that have N+n landscapes involving parallel Development systems, using a combination of features within the Product to avoid time-consuming, error-prone Dual Maintenance rekeying:
Each of these capabilities within ActiveControl is described in more detail later in the Administration Guide, along with the backend configuration required.
There are also many Target-level configuration options available to suit individual customer needs, that are configured via the frontend target configuration:
Conflict Analysis Options
| Property | Description |
|---|---|
| Perform conflict analysis against this target | When this option is enabled, ActiveControl will perform an additional remote analysis check for transport requests that are to be imported into this target system. The remote import analysis checks whether the content that is about to be imported has already been changed in the target system. This option is particularly useful for branched SAP development systems, when changes from one development system must be applied to other development systems. |
| Client to be used during conflict analysis | Client in which to check for changes and in which merge transport requests will be created. For performance reasons, the remote import analysis checks are only performed in one client of the target SAP system. Similarly, merge requests are only created in this client. You should specify the client of this target SAP system in which client-dependent configuration changes are made. |
Merge
| Property | Description |
|---|---|
| Create a merge transport request in this SAP system after importing changes | When this option is enabled, ActiveControl creates merge transport requests in this system for each selection of transport requests imported. |
| Require that transports with changes to SAP objects be manually merged | When this option is enabled, ActiveControl will check if a transport to be merged contains changes to SAP standard development objects and if so, require that the transport be manually merged. This option is useful if you have branched development systems that are running different versions or patch levels. |
| Merge Size | Select whether you want one merge transport for every originating transport (1:1), a big one with everything (Consolidated) or one per import run (By Import Run) |
| Merge Path | Select which path the Transport Forms for the merges will be created. Leave it blank if you want to create them manually. |
| Merge Type | Select which Type you want Merge Transport Form to be allocated to. If not set, the merge will get the type of the first transport merged. |
| Merge Group | Select which Group you want for the Merge Transport Form to be allocated to. If not set, the merge will get the group of the first transport merged. |
| Merge Task | Select which Task the Transport Form should be associated with. If not set, the merge will get the task of every transport merged. |
| For 1:1 merges automatically copy over Transport Form manual step details | Check if you want Manual Steps to be added in the Merge Transport Form in 1:1 merge scenario; it not relevant to the Consolidated Merge scenario. |
| For 1:1 merges make the merge transport form owner the same as the original owner | The default behaviour of ActiveControl is to assign Merge TOCs to the AC_RFC user. If this configuration option is switched on, then the Merge TOC will be assigned to the owner of the original source transport in the 1:1 Merge scenario. |
| For 1:1 merges copy custom fields to merge transport form | Check if you want the custom field values in the source Transport Form to be replicated in the Merge TOC Transport Form during 1:1 merge scenario. |
| For 1:1 merges, copy over dependencies to merge Transport Form | Check if you want the source transport hardcoded dependecies to be replicated in the new Merge TOC Transport Form during 1:1 merge scenario. Note that it will be the ToC’s that will be automatically defined in the Advanced Options tab, and NOT the original source transports. |
Merge Errors
| Property | Description |
|---|---|
| On Error | Controls whether ActiveControl Merge should stop, continue or skip any other errors encountered during the Merge process. |
| Stop on BW post-processing error | This option controls whether Merge process will stop or continue when BW postprocessing fails |
Advanced Merge
| Property | Description |
|---|---|
| Transport target for merge requests | This sets the transport target for merge requests created by ActiveControl, allowing merge transports to be handled via a different transport route if required. If not set the default value from TMS will be used. |
| Default package for merges objects | When BW objects are renamed sometimes they are not assigned with an object directory entry (TADIR). The package specified in here can be used to create this to prevent warnings during merge transport release |
| Fix renamed objects in merge requests | During import into BW systems some BW objects are automatically renamed. The default behaviour of the merge process is to copy the objects from the original transport into the merge transport but this doesn’t work for the affected BW objects. In this case ActiveControl can run a rename process either ‘After Import’, ‘Before Release’ or ‘After Import & Before Release’ to perform the renaming process. This will edit the merge transport and renaming the objects to the new names in the merged system. ‘After Import’ is the default renaming method. |
| Add dependant routines and formulae for BW merges | Some BW objects should always be transported in their entirety. If, for example, a transformation was being transported this option would also add in all the dependent routines and formulas into the merge transport. |
| Inherit merge transport owner from original transport (CTS+ only) | Check for Java systems to ensure Merge transport owner is same person as the original transport (for 1:1 Merge scenario) |
Post your comment on this topic.