Moving SEM BCS data/config from one BW instance to another

Hi Ramesh,

I didn't understand what you mean.

Below is the note # 627924. It is released for customer.

Restrictions with transport in BW-based SEM-BCS

Symptom

Systematic errors occur with Customizing transports in the SEM-BCS System.

Reason and Prerequisites

Due to the high flexibility of the application, the Customizing and the master data in the SEM-BCS System are stored in a way that the standard transport function of SAP is not sufficient for transports which means that extensive additional processing is necessary for application SEM-BCS during a transport. As a result, a lot of master data is stored in generated tables, which have different names in the various systems of the transport landscape and which also have different structures.

The transport function of the SEM-BCS System is implemented in a way that the system response is a similar as possible to the standard transport in the SAP System. Nevertheless, certain particularities and restrictions arise from the additional processing that is required, which should be observed when you create and execute Customizing transports.

Solution

Note the following rules during the transport:

If you transport a data basis which is defined without an RFC destination, the target client of the transport must be the BW client of the target system. Otherwise it is not possible to enter an RFC destination after the import either.

During the transport of the rules of the version combinations, you may not specify restrictions on the selection screen.

In general, the transports require no existing Customizing except for the settings of the transport tools. If you have distributed your Customizing to several transport requests, you can import these in any sequence. However, there are a few exceptions:

The import of the consolidation area requires that the respective data basis already exists or that it is created with this transport.

The import of the area of the Special Versions, as well as the import of the tasks, requires that the corresponding consolidation area already exists or that it is created with this transport.

The import of the consolidation unit combinations requires that the corresponding data basis already exists or that it is created with this transport.

If you transport master data, to characteristics to which a BW InfoObject corresponds, the import takes much longer if the corresponding data basis does not exist in the system yet and is not created with this transport either.

If an RFC destination is specified in the data basis, it is not necessary that this RFC destination exists during the import of the transport request with the data basis. However, you must create or adjust the RFC destination in this case immediately after the import. In particular you have to create it also before the import of additional Customizing transports.

Note that these prerequisites also become necessary because corresponding transport entries exist in the transport request, even if you have deleted the corresponding Customizing in the meantime. If you have recorded tasks for a consolidation area XY in the request, for instance, and have deleted this consolidation area in the meantime, consolidation area XY must still exist in the target system for the import of this transport request and must not be deleted with the request either.

Customizing and master data of the SAP consolidation are primarily stored in tables, which are not created until the application is customized. If the Customizing of the application changes, these tables may also be changed. Changes to the role assignments, as well as changes to the definition of the InfoObjects in the BW system, are examples of such changes. The Customizing in these tables is adjusted automatically as far as possible. However, this is not possible for the Customizing transports. These might be invalidated by such a change. Therefore, you may no longer be able to use existing transport requests after such changes.

The individual Customizing objects of the SAP consolidation are often assemble from a larger number of independent subobjects. For instance, a typical method contains several selection conditions which in turn are assembled from selections on individual characteristics. This structure cannot be taken into account completely with the manual creation of a request because changes can still occur up to the release. Therefore, the system first determines the complete scope of the transport structure with the release of this subobject structure of the selected Customizing objects. However, this is not always possible. In particular, formulas in validations and in the manual entry of totals data cannot be added to the request with the export. Therefore, the system only transports the formulas with validations and data entry layouts which already existed at the time of creation of the transport request. If you create more formulas or change existing ones between the time of creation and the release of the request, the request might result in incomplete and thus incorrect Customizing in the target system.

If you transport methods that are based on method layouts, the method layout must also have been transported from the system in which the method was created. It is not enough to create a method layout with the same key in the target system. If you simultaneously create and import methods in different systems of the transport landscape, it may not be possible to transport these methods using manual transports:

Let us assume you have three systems D, Q and P. Customizing is transported from D to Q and from Q to P. You create method layout L1 in D and Q. You also create method M1 for method layout L1 in Q. You then transport L1 from D to Q. If you now create a transport request in Q that contains M1 and L1, the order contains the method M1 that refers to the L1 created in Q as well as the L1 created in D. In the system Q there is also a reference from the L1 created in Q to the L1 created in D, so that M1 does in fact use the L1 created in D. However, this reference cannot be included in the transport request. To avoid this, you must follow one of the following rules:

Customizing should either be maintained or imported in a system, not both.

If you maintain the Customizing in a subordinate system, this must be maintained in the development system. So, in the example given above, you would have to also create method M1 in D and transport it together with L1 to Q.

If you maintain Customizing in a subordinate system, this must be transported on before transports, which may contain Customizing components of the Customizing maintained there, are imported. In the example you would have had to transport L1 and M1 from Q to P before the order with L1 from D is imported in Q or P.

Use automatic transport recording.

The points mentioned for method layouts also apply to reusable structures and reusable forms of manual data entry, for reusable individual selections as well as for methods of certain method types such as rounding, flexible uploads, validations or currency translations.

At some points in the Customizing of the SAP consolidation you can choose whether to enter the desired settings directly or access existing settings. You can therefore define structures directly in the definition of the manual data entry layouts or assign already defined reusable structures. There are differences between both cases during the transport:

If you are using elements that are not reusable, these are automatically transported during the transport of the higher-level Customizing. So if you enter a structure that cannot be reused, it is transported when you transport the data entry layout.

If you use reusable elements, you must transport these separately. If you assign a reusable structure, you must include it explicitly in the transport request - this does not happen automatically when the data entry layout is transported. This is in keeping with the principle that separately maintainable entities are also transported separately.

This system response only applies as of Release 3.2. Under Release 3.1 the system did not yet recognize whether a value is reusable or not and partial elements were therefore always transported as a precaution.

When you manually create a transport request, you can only apply restrictions using the fields that are available on the selection screen. It is therefore not possible to apply restrictions to a version or to a period. Furthermore, restrictions to a consolidation area are only possible if the consolidation area is available for selection on the selection screen. The exception to this is the assignment of special versions to version combinations, to the settings for saving additional financial data for each special version and the assignment to the settings for MultiProvider Reporting. These exceptions are only ever indicated for the consolidation area from the global parameters in the transport request, even if the consolidation area is not available on the selection screen.

SAP Recommendations

For the initial system setup, and after substantial changes in the data model, you should transport the Customizing by means of manually created transport requests. We advise you not to use the automatic recording of all Customizing settings during the first implementation phase in the development system and not to use this request for the structure of the test and productive systems.

During the transport of a new consolidation area, the following settings should be transported in the following sequence:

1. Data basis

2. Consolidation area

3. Special versions

After the import of the data basis and the consolidation area, these settings should be checked in the target system. In particular, the RFC destination, the InfoCubes and ODS objects, as well as the InfoObjects. Note that RFC destinations, InfoCubes, ODS objects, virtual cubes and InfoObjects cannot be transported from the consolidation workbench with the transport functions. For instance, you have to transport and activate the InfoCubes and InfoObjects using the BW.

When you delete a consolidation area, you have to be particularly careful. Complete all open Customizing requests as well as their transport requests. Then delete the consolidation area and record this deletion in a separate transport request. Then transport this request. The transport requests that were recorded before the deletion must no longer be used after the transport of the deletion, not even to compile new requests.

SAP strongly recommends a similar procedure for the deletion of a data basis and when you change the data model. In particular, the change of the characteristic list in the data basis or in the consolidation area, the change of the role assignment and the change of used InfoObjects or InfoCubes come under this category.

In general, manually created transport requests ought to be released timely.

Generally is valid that transport requests always have to be imported in exactly the same sequence as how they were exported.

Best regards,

Eugene