Overview

With the help of SCC1N it is possible to copy customizing objects recorded in transport requests to several target clients. This can be a local transport request or an imported transport request from another system. In contrast to R3TRANS, no transport path needs to be set up here.

The new SCC1N is released for customers from 2020 SP01.

Transaction SCC1N is a refactored successor of the old transaction SCC1 and the old report RSCC_SCC1_BATCH.

What is SCC1N?

Usage Scenarios

SCC1N allows the cascading of customizing objects from one source client to several target clients. The request can either come from another system or from the local system. Local transport requests can, but do not have to be released in order to copy them. SCC1N can therefore also be used to copy local changes in a customizing client to a test client and test them there directly. Figure 1 shows the classical use case of SCC1N in a single system:

Scenario 1: Copying of Customizing from a Source to a Target Client

In contrast to the old SCC1 transaction, the SCC1N transaction also supports the cascading of customizing in any number of target clients. SCC1N only needs to be configured once in a client. This is shown in Figure 2.

Copying of Customizing from a Source to Multiple Target Clients

Another popular scenario is cascading customizing from a development system into multiple target clients in a test system. This is shown in Figure 3.

Execution Phases

SCC1N runs in three phases. The actual copying process of the table data takes place in phase 2. If the transport request also contains logical transport objects, their before-export methods are processed in phase 1 and their after-import methods in phase 3 after the copy process. Typically, after-import methods are used to refresh dependent tables, such as caching tables.

New Features of SCC1N and Differences to SCC1

SCC1N is a further development of transaction SCC1 and the batch job report RSCC_SCC1_BATCH. SCC1N comes with a significantly expanded selection screen for this purpose. The figure below shows the main differences.

Multi-Client-Support: No Logon to Target Client Required

In contrast to the old SCC1 transaction, you need not log into target client. For example, in client 000 you can set up client cascading for several target clients in the target system. A logon in each individual target client is no longer necessary for client cascading.

Multi-Transport-Support

SCC1N combines and enhances the old transaction SCC1 and the previous batch report RSCC_SCC1_BATCH. This allows you to copy several transports to the target clients in one run. SCC1N can be scheduled and executed once in client 000 (or another client).

Enhanced Selection Criteria

For the selection of transports, SCC1N offers a variety of new selection criteria:

• Transport Request related criterias. This includes the Transport Request, Type of Request, Target, User and CTS Project(s)
• Table related criterias. Tables on transport requests can be filtered by the Delivery Class.
• Source System Source Client. To prevent transports from being selected and copied from several source clients, the source client of the transports to be copied must always be specified.
• Export/Import time of a Transport Request. With this filter criterion, all transports that have been imported or exported since a key date can be selected. This makes particular sense with strict release cycles, for example if you only want to select and copy objects since the beginning of the current development cycle.

Variants for Regular Batch-Scheduling

By using export/import variants, it is possible to run the transaction regularly as a batch job, and only to cascade the transports newly imported into the system. All you have to do is specify a variant name and the initial export/import times.

Example of Export-/Import-Variants

You can then schedule the SCC1N as a regular batch job. Under the variant name, transaction SCC1N now saves for each target client when the report last imported transports into this client. If a new transport is imported into the system, the SCC1N recognizes this during the next batch run and copies it.

If you extend an existing variant and, for example, add a new client, all transports since the specified export/import date are selected and copied for this during the first run.

New Log

Like the Client Copy Tool, transaction SCC1N is now delivered with a new tab-based log. If required, logs can be downloaded as a file and attached to incidents.

SCC1N and the new Client Copy Tool

SCC1N is based on the new Client Copy Tool Architecture. It uses a special Client Copy Profile which read

• Objects of Transport Requests and
• Views and Logical Objects

for later processing by the Client Copy Tool and its algorithms.

In comparison to the Client Copy Tool SCC1N supports Table Change Log (DBTABLOG).

SCC1N provides an Insert-Only-Mode which ensures that existing customizing is not deleted but only updated.

SCC1N uses a Delta-Data-Copy-Algorithm comparing two clients and updating only deleted or changed records.

Tasklist Support

SAP delivers the task list SAP_CLIENT_COPY_BY_TRANSPORT for use in the tasklist framework.

Related Information

Since the release of SCC1N with SAP_BASIS 755, some important corrections have been made. To ensure stable operation, I recommend switching to the latest service pack before using the transaction in SAP_BASIS 755 and 756 and importing all the notes available for SCC1N.

You can find further information in my blog post about the new Client Copy Tool.